On 10/25/06, David Binger  wrote:
> You can set the class of the root object to something else
> after the constructor is called.

How would you do that?

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

Is the root object different than other persistent objects in some way
I don't understand?  Doesn't Durus load and save it like any other
object?  Why should Durus care whether it has slots or not?  Doesn't
Durus just instantiate it, insert it in the database, and forget about
it?

If the root object has to have certain slots, it's not the end of the
world.  But it seems a pity to make Durus less flexible unless there's
a compelling reason to.

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

..__getstate__ exists in Python to support pickling and the copy
module. No other Python package I know of uses .__getstate__ as a
substitute for .__dict__ or vars().  The logical alternative is:
    dict((x, getattr(obj, x)) for x in obj.__slots__)
though I suppose we can mention .__getstate__ as an alternative that
happens to work.

--
Mike Orr