ombdalen at gmail
Aug 4, 2012, 8:04 PM
Post #5 of 10
On Thu, Aug 2, 2012 at 5:55 PM, Ethan Furman <ethan [at] stoneleaf> 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.
I agree that the flag would be more pythonic in dbf.py.
I was not aware that you are adding sqlite functionality to your
library. This is very cool!
I have been through the same questions with my own DBF library, and
I've come to some conclusions: First, I decided to make the library
read-only and in-memory. That is all we need in-house anyway. Second,
I decided to make an external tool for converting DBF files to sqlite:
(To anyone reading: I have not yet made a public announcement of
dbfget, but I will shortly. Consider this an informal announcement:
I am considering adding a "streaming=True" flag which would make the
table class a record generator, and a "save()" method which would
allow you to save data back to the file, or to a new file if you
provide an optional file name. In fact, I had this functionality in
earlier versions, but decided to chuck it out in order to make the API
as clean as possible.
I hope this can help you somehow in your decision making process.