persistent composites

Aaron Brady castironpi at
Mon Jun 15 12:18:48 EDT 2009

On Jun 15, 8:37 am, a... at (Aahz) wrote:
> In article <79mtt7F1r480... at>,
> Diez B. Roggisch <de... at> 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 mailing list