durusmail: durus-users: Durus Change Preview
Durus Change Preview
2006-10-25
2006-10-25
2006-10-25
2006-10-25
2006-10-25
2006-10-25
2006-10-25
2006-10-25
2006-10-25
2006-10-25
2006-10-31
2006-10-31
Durus Change Preview
David Binger
2006-10-25
Thanks Mike.

On Oct 25, 2006, at 1:07 PM, Mike Orr wrote:

>
> Setstate never promised to preserve existing attributes anyway.

Right, and I think the current behavior, that in theory allows
for some attributes to be preserved, is incorrect.

>
>> 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.

You can set the class of the root object to something else
after the constructor is called.  This class change will, however,
be made more difficult by the revision I have described today.
You can't change the class to something with an incompatible
set of slots.

> 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.

Understood.

>
>> 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.


We already require __getstate__(), and it happens to do just what
we need.  Is there some more attractive alternative?


reply