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

[Neil Girdhar]

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

>
> On 7 Jun 2014 16:37, "Neil Girdhar" <mistersheik at gmail.com> wrote:
> > 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.
>
> As far as I am aware, it's not implemented in two places - I believe copy
> falls back pickling & unpickling if there's no other copy operation defined.
>
> We don't try to jam everything into the base object, as library protocols
> are easier to evolve without breaking backwards compatibility. (For
> CPython, there's also the practical consideration that "object" methods
> have to be implemented in C, so having protocol fallbacks in the standard
> library sometimes makes them easier to work on).
>
I see your point.

> >> > 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?
>
> A reference is a 64-bit pointer. That would be additional overhead on
> *every single object*. All ints, all strings, all tuples, all dicts(!),
> etc. Saving 8 bytes per object adds up fast, which is why a lot of the core
> types (including object itself) don't have a per-instance __dict__
> attribute.
>
> Keeping objects as small as possible also impacts how many will fit in the
> CPU cache, so this approach can end up providing a speed increase as well.
>

Right, that makes sense.  I think the flyweight pattern would eliminate
this: use a special representation for the common case and then switch to a
real representation as soon as things become weird.  (I can see how that
would be extra development time unless it could be done automatically by a
clever JIT.)

Best,

Neil


> Cheers,
> Nick.
>
> >
> >>
> >>
> >> 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/34d5c5c6/attachment-0001.html>