[Tim Peters]
> > ...
> > On ZODB head, Jeremy also documented that __setstate__ can't affect the
> > persistent state (in persistent/interfaces.py's IPersistent).  Whether
> > this is deliberate design, or a consequence of the current
> > implementation, I can't say.

[Dieter Maurer]
>  A potential problem: it *can* change the persistent state but it does not
>  do it reliably. It does precisely when the object is later modified
>  again: in this case modifications made in "__setstate__" become
>  persistent, otherwise, they do not.

I agree, but the docs are cryptic (because so brief) enough that I can read
them as being correct or incorrect:


    def __setstate__(state):
        """Set the object state data

        Note that this does not affect the object's persistent state.
        """

There are enough ambiguities there to fill a whole thread <wink> .  It is
true that a call to __setstate__() alone doesn't affect the object's state
in the DB.  It needs more words.  OTOH, I'd rather dream up a way to make
object changes made in __setstate__() persistent, if desired.  For example,
__setstate__'s return value is ignored now.  Perhaps we could say that if it
returns True, then the object should be considered to be in the changed
state rather than in the uptodate state.


_______________________________________________
Zope-Dev maillist  -  Zope-Dev@[...].org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )