David Binger writes:
> The impact on speed of one more self lookup is extremely low relative to
> the other things going on.  That's not the problem here.

I wouldn't have thought the speed impact would be significant, either,
although I hadn't really considered it, and I thought Pat was right to
raise the issue.

> There is a problem though, and it is that this would break existing
> code.  We have subclasses of PersistentList that have data_is values
> that don't work as constructors:  they just add on the additional
> requirement that the elements of the list are of a certain type.

Oh, rats.  Since PersistentList acts as a proxy object for list, I kind
of hoped that 'data_is' had been added as a way to customise the type of
the list that was proxied, but that the implementation had just never
been finished.  Looks like I was wrong.

> I'm curious, though, Andrew.  What is the objective of your list
> subclass?

I have several "interesting" subclasses of list (and dict, and set)
which predate my use of Durus, and I would like to persist them in a
Durus db without having to modify their code.  They can't just be made
subclasses of PeristentList, since they are general-purpose classes that
are (re)used in various projects that doesn't depend on Durus.  I
suppose I could add calls to _p_note_change() throughout my classes, and
dual-inherit from my list subclasses and PersistentObject to make the
persistent versions, and provide a no-op _p_note_change method for when
PersistentObject is absent.  But I would prefer to keep all trace of
persistence out of my list subclasses, because separation of concerns is
an important consideration in reused code.

My "interesting" subclasses mostly do type enforcement to ensure
homogeneity of list elements.  Others support a limited kind of
repr-eval based pickling (without actually using eval to unpack --
yikes) which I use to serialise data in a much more compact,
Python-independent, but less general form than pickle, in order to store
structured data in user agent cookies in a web app, among other things.
I have other list subtypes which, as yet, I have not needed to persist,
which send messages to notify of changes.  They would probably fit quite
nicely with PersistentList.

--
Andrew Bettison