On 10/25/06, David Binger  wrote:
> The recent discussion here (initiated by Patrick K. O'Brien)
> about slots and RAM requirements
> motivated me to try some changes in the durus development
> tree.  I'm wondering what people will think about them, so
> I'll describe them here.

Fine by me.  We'll just need upgrade warnings in the announcements and README.

> 1) The Persistent class is split into two classes, so that
> Persistent inherits from a new PersistentObject class.
> Instances of Persistent do have a __dict__, just like before.
> Direct instances of PersistentObject, like direct instances of
> "object",  don't have __dict__ attributes.

Shouldn't affect existing applications, so no problem.

> 2) __setstate__() now clears all data attribute values before
> it sets the new values using the argument it is given, which
> may be a dict or None.

Setstate never promised to preserve existing attributes anyway.

> 3) The base class of PersistentDict, PersistentList,
> PersistentSet, and BTree, and BNode classes is changed from
> Persistent to PersistentObject, and __slots__ attributes
> are put on those classes, so that direct instances of
> these classes don't have __dict__ values.
>
> Before this change, you could set arbitrary attributes on
> direct instances of these container classes.  After the
> change, you can't do that.

Doesn't matter to me now.  The only reason this came up is that
the root object is a PersistentDict and is not overridable.  I still suggest a
callable arg in the storage constructor that if present returns an
initialized root object (any subclass of PersistentObject) to seed the
database if it doesn't exist.  This both allows for an alternate root
class and provides a convenient place to put your database-setup code;
e.g., to set up the empty collections needed by the rest of the
application.

> In the new arrangement, applications that access __dict__
> directly, or that use vars(), should instead use __getstate__().
> __getstate__() will be expected to return either
> a dict or None.

As a patch to avoid rewriting an existing application, OK. But that's
really not what getstate was intended for.

--
Mike Orr