<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 1, 2013 at 8:15 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2013/1/1 Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>>:<br>
<div><div class="h5">> Hello and happy 2013,<br>
><br>
> Something I noticed earlier today is that some C versions of stdlib modules<br>
> define their name similarly to the Python version in their PyTypeObject.<br>
> Some examples: Decimal, xml.etree's Element. Others prepend an understore,<br>
> like _pickle.Pickler and many others.<br>
><br>
> What are the tradeoffs involved in this choice? Is there a "right" thing for<br>
> types that are supposed to be compatible (i.e. the C extension, where<br>
> available, replaces the Python implementation seamlessly)?<br>
><br>
> I can think of some meanings for pickling. Unpickling looks at the class<br>
> name to figure out how to unpickle a user-defined object, so this can affect<br>
> the pickle/unpickle compatibility between the C and Python versions. What<br>
> else?<br>
<br>
</div></div>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.<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Hi Benjamin,<br><br></div><div>Can you elaborate - what you mean by "is directly exposed through the API"?<br>

<br>For example, Pickler in 3.x:<br><br>>>> import pickle<br>>>> pickle.Pickler.__name__<br>'Pickler'<br>>>> pickle.Pickler.__module__<br>'_pickle'<br> <br></div></div><br></div>

</div>