<div dir="ltr">Hi,<div><br></div><div>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.<div>
<br></div><div>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?</div>
<div><br></div><div>Best,</div><div><br></div><div>Neil</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 7, 2014 at 3:12 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">You haven't explained why you need this. You just stated a proposal. </p>
<div class="gmail_quote"><div><div class="h5">On Jun 7, 2014 12:06 PM, "Neil Girdhar" <<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>> wrote:<br type="attribution"></div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div>Best, Neil</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 7, 2014 at 5:34 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 7 June 2014 18:46, Neil Girdhar <<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>> wrote:<br>
><br>
> Right, that makes sense. I think the flyweight pattern would eliminate<br>
> this: use a special representation for the common case and then switch to a<br>
> real representation as soon as things become weird. (I can see how that<br>
> would be extra development time unless it could be done automatically by a<br>
> clever JIT.)<br>
<br>
</div>The flyweight pattern imposes its own costs in terms of additional<br>
levels of indirection and even more pointers to carry around. The<br>
approach we take is that object instances get a __dict__ attribute by<br>
default, unless the creator of the class decides "there are going to<br>
be enough of these for it to be worth skipping the space not only for<br>
the attribute dicts themselves, but also for the attribute dict<br>
reference on each instance". We do the same with weakref support.<br>
<br>
The other thing to keep in mind is that many of CPython's "internal"<br>
representations aren't actually internal: many of them are exposed in<br>
various ways through the CPython C API. As other implementations have<br>
discovered, preserving full compatibility with that API places some<br>
pretty significant constraints on the implementation techniques you<br>
use (or else means putting a lot of work into a compatibility shim<br>
layer like IronClad, JyNI or cpyext).<br>
<br>
Cheers,<br>
Nick.<br>
<div><div><br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</div></div></blockquote></div><br></div>
<br></div></div><div class="">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a><br></div></blockquote></div>
</blockquote></div><br></div>