On Thu, Aug 2, 2012 at 5:55 PM, Ethan Furman <et...@stoneleaf.us> 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. > > Thoughts?
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: https://github.com/olemb/dbfget/blob/master/extras/dbf2sqlite (To anyone reading: I have not yet made a public announcement of dbfget, but I will shortly. Consider this an informal announcement: https://github.com/olemb/dbfget/ ) 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. -- http://mail.python.org/mailman/listinfo/python-list
