[Python-ideas] Put default setstate and getstate on object for use in coöperative inheritance.

[Neil Girdhar]

On Sat, Jun 7, 2014 at 2:18 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 7 June 2014 16:05, Neil Girdhar <mistersheik at gmail.com> wrote:
> > I use cooperative multiple inheritance throughout my (large-ish) project,
> > and I find it very comfortable and powerful.  I am currently using the
> class
> > below to serve as an anchor point.  The thing is that this behavior is
> > already implemented somewhere in Python (where?) since it is the default
> > behaviour if getstate or setstate don't exist.  Why not explicitly make
> it
> > available to call super?
>
> There is fallback behaviour in the pickle and copy modules that
> doesn't rely on the getstate/setstate APIs. Those fallbacks are
> defined by the protocols, not by the object model.
>

Those fallbacks are essentially default implementations of setstate and
getstate.  It seems to me like it would make sense to implement those
fallbacks once rather than twice in the various places that you mention.


>
> https://docs.python.org/3/library/pickle.html#pickle-inst covers the
> available protocols for instance pickling.
> https://docs.python.org/3/library/copy.html covers (towards the end)
> some of the options for making class instances copyable
>

Yes, personally, I prefer writing setstate and getstate and getting copy
for free rather than writing a separate __copy__ method.


> https://docs.python.org/3/library/copyreg.html is an additional
> registry that allows third parties to make instances of classes
> defined elsewhere support pickling and copying without relying on
> monkeypatching.
>

copyreg is unfortunately no use for cooperative inheritance as far as I can
see.  The whole point is for each class to pickle what it needs to and
delegate the rest of the pickling to super.


>
> > I think I saw or got an email from Guido that I can't seem to find that
> > rightly points out that object doesn't have __dict__ so this can't be
> done.
> > I'm curious why object doesn't have __dict__?  Where does the __dict__
> comes
> > into existence?  I assume that objects of type object and instantiated
> > objects of other types have the same metaclass; does the metaclass treat
> > them differently?
>
> Types defined in C extensions and those defined dynamically on the
> heap share a metaclass at runtime, but their initialisation code is
> different. You can also define Python level types without a __dict__
> by declaring a __slots__ attribute with no __dict__ entry (for
> example, collections.namedtuple uses that to ensure namedtuple
> instances are exactly the same size as ordinary tuples - the mapping
> from field names to tuple indices is maintained on the class).
>

Very interesting, thanks for explaining what is happening.  I don't see why
__dict__ isn't just in object though.   Is it just for the (minor)
efficiency of saving an empty dict reference?


>
> Cheers,
> Nick.
>
> P.S. Posting through Google Groups doesn't work properly - it messes
> up the reply headers completely. gmane does a better job of
> interoperating with the mailing list software (as far as I am aware,
> Google just don't care whether or not interaction with non-Google
> lists actually works)
>

Sorry, I'm just answering via email.  I don't know anything about gmane.

>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140607/c43a1af3/attachment.html>