2013/1/1 Eli Bendersky <eliben@gmail.com>:
> Hello and happy 2013,
>
> Something I noticed earlier today is that some C versions of stdlib modules
> define their name similarly to the Python version in their PyTypeObject.
> Some examples: Decimal, xml.etree's Element. Others prepend an understore,
> like _pickle.Pickler and many others.
>
> What are the tradeoffs involved in this choice? Is there a "right" thing for
> types that are supposed to be compatible (i.e. the C extension, where
> available, replaces the Python implementation seamlessly)?
>
> I can think of some meanings for pickling. Unpickling looks at the class
> name to figure out how to unpickle a user-defined object, so this can affect
> the pickle/unpickle compatibility between the C and Python versions. What
> else?

I don't it's terribly important except if the object from the C module
is directly exposed through the API it's nicer if it's __name__
doesn't have a leading underscore.

Hi Benjamin,

Can you elaborate - what you mean by "is directly exposed through the API"?
">

(original) (raw)




On Tue, Jan 1, 2013 at 8:15 AM, Benjamin Peterson <benjamin@python.org> wrote:
2013/1/1 Eli Bendersky <eliben@gmail.com>:
> Hello and happy 2013,
\>
\> Something I noticed earlier today is that some C versions of stdlib modules
\> define their name similarly to the Python version in their PyTypeObject.
\> Some examples: Decimal, xml.etree's Element. Others prepend an understore,
\> like \_pickle.Pickler and many others.
\>
\> What are the tradeoffs involved in this choice? Is there a "right" thing for
\> types that are supposed to be compatible (i.e. the C extension, where
\> available, replaces the Python implementation seamlessly)?
\>
\> I can think of some meanings for pickling. Unpickling looks at the class
\> name to figure out how to unpickle a user-defined object, so this can affect
\> the pickle/unpickle compatibility between the C and Python versions. What
\> else?

I don't it's terribly important except if the object from the C module
is directly exposed through the API it's nicer if it's \_\_name\_\_
doesn't have a leading underscore.

Hi Benjamin,

Can you elaborate - what you mean by "is directly exposed through the API"?


For example, Pickler in 3.x:

>>> import pickle
>>> pickle.Pickler.__name__
'Pickler'
>>> pickle.Pickler.__module__
'_pickle'