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

[Guido van Rossum]

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/599185f8/attachment-0001.html>