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' -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130101/a342c0ee/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4