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

[Neil Girdhar]

Hi,

Okay. In my project I have many classes multiply inheriting from each
other.  Most of these classes derive from "NetworkElement" and objects of
this type are stored in a tree.  I would now like to serialize the tree of
objects so that I can save the state of the network.  I would also like to
instantiate copies of the tree so that I can rewind the state of the
network to given checkpoints and play back the simulation.  The easiest way
to implement both serialize and copy in such a way that they are consistent
(serialization and deserialization is equivalent to copy) is to implement
setstate and getstate.

In cooperative inheritance, the general pattern is to call super and do
whatever is particular to your class around that.  I needed to inherit from
the mixin I displayed at the top of this message in order to provide a
default setstate and getstate as these are not present in object.
 Intuitively, I think that it would be better for these to exist on object.
 I don't think I should have to provide these methods using a mixin.  It's
not a big deal, but I think it's a small wrinkle in Python not to have
default implementations of these methods given that that default behavior
is being done anyway.  Are there any drawbacks to providing these default
methods?

Best,

Neil


On Sat, Jun 7, 2014 at 3:12 PM, Guido van Rossum <guido at python.org> wrote:

> You haven't explained why you need this. You just stated a proposal.
> On Jun 7, 2014 12:06 PM, "Neil Girdhar" <mistersheik at gmail.com> wrote:
>
>> I understand your concern for cpython, but I don't think it will be the
>> future of Python.  I think every object should have a dict and then the JIT
>> should just make it fast.  I think that's possible.
>>
>> Anyway, this is a separate discussion.  My new proposal is for setstate
>> and getstate to have default implementations that first check for the
>> __dict__ attribute and do the normal thing (getstate returns {}, setstate
>> does nothing) if it doesn't exist.
>>
>> Best, Neil
>>
>>
>> On Sat, Jun 7, 2014 at 5:34 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 7 June 2014 18:46, Neil Girdhar <mistersheik at gmail.com> wrote:
>>> >
>>> > 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.)
>>>
>>> The flyweight pattern imposes its own costs in terms of additional
>>> levels of indirection and even more pointers to carry around. The
>>> approach we take is that object instances get a __dict__ attribute by
>>> default, unless the creator of the class decides "there are going to
>>> be enough of these for it to be worth skipping the space not only for
>>> the attribute dicts themselves, but also for the attribute dict
>>> reference on each instance". We do the same with weakref support.
>>>
>>> The other thing to keep in mind is that many of CPython's "internal"
>>> representations aren't actually internal: many of them are exposed in
>>> various ways through the CPython C API. As other implementations have
>>> discovered, preserving full compatibility with that API places some
>>> pretty significant constraints on the implementation techniques you
>>> use (or else means putting a lot of work into a compatibility shim
>>> layer like IronClad, JyNI or cpyext).
>>>
>>> Cheers,
>>> Nick.
>>>
>>> --
>>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>>
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140607/6856e631/attachment.html>