[Python-Dev] PyTypeObject type names in Modules/

[Benjamin Peterson]

2013/1/1 Eli Bendersky <eliben at gmail.com>:
>
>
>
> On Tue, Jan 1, 2013 at 8:15 AM, Benjamin Peterson <benjamin at python.org>
> wrote:
>>
>> 2013/1/1 Eli Bendersky <eliben at 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'

That's an example of what I meant.


-- 
Regards,
Benjamin