dbf.py API question

Fri Aug 3 09:11:59 EDT 2012

Peter Otten wrote:
> Ethan Furman wrote:
>>> SQLite has a neat feature where if you give it a the file-name of
>> ':memory:' the resulting table is in memory and not on disk. I thought
>> it was a cool feature, but expanded it slightly: any name surrounded by
>> colons results in an in-memory table.
>>>> I'm looking at the same type of situation with indices, but now I'm
>> wondering if the :name: method is not pythonic and I should use a flag
>> (in_memory=True) when memory storage instead of disk storage is desired.
>> For SQLite it seems OK because you make the decision once per database. For 
> dbase it'd be once per table, so I would prefer the flag.

So far all feedback is for the flag, so that's what I'll do.
> Random
>>> Thoughts?
>> - Do you really want your users to work with multiple dbf files? I think I'd 
> rather convert to SQLite, perform the desired operations using sql, then 
> convert back.

Seems like that would be quite a slow-down (although if a user wants to 
do that, s/he certainly could).
> - Are names required to manipulate the table? If not you could just omit 
> them to make the table "in-memory".

At one point I had thought to make tables singletons (so only one copy 
of /user/bob/scores.dbf) but that hasn't happened and is rather low 
priority, so at this point the name is not required for anything beside 
initial object creation.
> - How about a connection object that may either correspond to a directory or 
> RAM:
>> db = dbf.connect(":memory:")
> table = db.Table("foo", ...)

dbf.py does not support the DB-API interface, so no connection objects. 
 Tables are opened directly and dealt with directly.
All interesting thoughts that made me think. Thank you.
~Ethan~