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

[Nick Coghlan]

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

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/5b9b4fe4/attachment.html>