castironpi at gmail.com
Mon Jun 15 18:18:48 CEST 2009
On Jun 15, 8:37 am, a... at pythoncraft.com (Aahz) wrote:
> In article <79mtt7F1r480... at mid.uni-berlin.de>,
> Diez B. Roggisch <de... at 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)
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.
More information about the Python-list