2013/1/1 Eli Bendersky <eli...@gmail.com>: > > > > On Tue, Jan 1, 2013 at 8:15 AM, Benjamin Peterson <benja...@python.org> > wrote: >> >> 2013/1/1 Eli Bendersky <eli...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
