On Jun 15, 8:37 am, a...@pythoncraft.com (Aahz) wrote: > In article <79mtt7f1r480...@mid.uni-berlin.de>, > Diez B. Roggisch <de...@nospam.web.de> wrote: > > >Aaron Brady wrote: > > >> Some time ago, I recommended a pursuit of keeping 'persistent > >> composite' types on disk, to be read and updated at other times by > >> other processes. Databases provide this functionality, with the > >> exception that field types in any given table are required to be > >> uniform. Python has no such restriction. > > >> I tried out an implementation of composite collections, specifically > >> lists, sets, and dicts, using 'sqlite3' as a persistence back-end. > >> It's significantly slower, but we might argue that attempting to do it > >> by hand classifies as a premature optimization; it is easy to optimize > >> debugged code. > > >Sounds like you are re-inventing the ZODB. > > ...or SQLAlchemy or pickles in a SQL BLOB or...
I recognize your aversion to my claim of making a new approach on something. I suppose an austere review of literature would compare with the existing alternatives. My approach does not define tables, so it is not SQL Alchemy; it is not mere sugar for SQL. It defines a 'set' class and a 'tuple' class, so some of the functionality may (and probably should be expected to) overlap. http://www.sqlalchemy.org/docs/05/ormtutorial.html#define-and-create-a-table My approach does not pickle objects, so it is not a mere BLOB pickle. If a user writes, listA[ 50 ].append( "abcde" ), one addition is made to an existing structure, and the remaining contents of 'listA' are unread and unchanged. -- http://mail.python.org/mailman/listinfo/python-list
