<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 3, 2013 at 6:43 AM, Benjamin Peterson <span dir="ltr"><<a href="mailto:benjamin@python.org" target="_blank">benjamin@python.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/1/3 Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>>:<br>
<div><div class="h5">><br>
><br>
>> >><br>
>> >> 2013/1/1 Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>>:<br>
>> >> > Hello and happy 2013,<br>
>> >> ><br>
>> >> > Something I noticed earlier today is that some C versions of stdlib<br>
>> >> > modules<br>
>> >> > define their name similarly to the Python version in their<br>
>> >> > PyTypeObject.<br>
>> >> > Some examples: Decimal, xml.etree's Element. Others prepend an<br>
>> >> > understore,<br>
>> >> > like _pickle.Pickler and many others.<br>
>> >> ><br>
>> >><br>
>> >> I don't it's terribly important except if the object from the C module<br>
>> >> is directly exposed through the API it's nicer if it's __name__<br>
>> >> doesn't have a leading underscore.<br>
>> ><br>
><br>
><br>
> As a followup question: would it be considered a compatibility-breaking<br>
> change to rename PyTypeObject names? As a concrete example, in<br>
> Modules/_elementtree.c the name of Element_Type (essentially the<br>
> xml.etree.ElementTree.Element replacement in C) is "Element". For the<br>
> purpose of pickling/unpickling it should be named "_elementtree.Element" or<br>
> "xml.etree.ElementTree.Element" or some such thing. Can such a change be<br>
> made between 3.3 and 3.4? Between 3.3 and 3.3.1?<br>
<br>
</div></div>I don't know much about etree. Can you pickle Element?<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>etree has a C accelerator that was improved and extended in 3.3 and was made the default when importing etree. But a regression (issue #16076) occurs because _elementree.Element has no pickling support, while the Python version does by default (being a plain Python class). In the aforementioned issue we're trying to resolve the strategy for supporting pickling for _elementtree.Element. I hope my understanding of unpickling is correct - it does need a class name to find the module that can unpickle the object, right? If this is correct, than such a change (name of the type) may be required to solve the regression between 3.3 and 3.3.1<br>

<br>Eli<br></div><div> </div></div><br></div></div>