Author brett.cannon
Recipients belopolsky, brett.cannon, brian.curtin, daniel.urban, lemburg, r.david.murray
Date 2010-06-08.00:58:47
SpamBayes Score 0.00193059
Marked as misclassified No
Message-id <>
So I see a couple of objections here to the idea that I will try to address.

First is MAL's thinking that this will undo any C code, which it won't. The idea is that stdlib modules that do not inherently rely on other C code (e.g. sqlite3 does not fall underneath this) would have a pure Python implementation with possible C enhancements. In the case of datetime that  code is done, so it won't go anywhere. In this case it would be bringing in a pure Python implementation like the one PyPy maintains. You can look at heapq if you want an existing example of what it looks like to maintain a pure Python and C version of a module.

Alexander is worried about performance because of Python shims and duplication of work. For the performance issue, there is none. If you look at something like heapq you will see that there is an `import *` in there to pull in all extension code; there is no Python shim to pass through if you don't engineer the extension that way. So in datetime's case all of the extension code would just get pulled into directly and not have any indirection cost.

As for duplication of work, we already have that with datetime in the other Python VMs. IronPython, Jython, and PyPy have to do their own version of datetime because the stdlib doesn't provide a pure Python version for them to use. So while CPython might not be duplicating work, other people are. Besides, people typically prototype in Python anyway (including you, Alexander, for the UTC patch) and then write the C code, so there really isn't any wasted development cycles by having the Python and C version already.

The key thing to remember is that this is so the VMs other than CPython are not treated as second-class. They are legit implementations just like CPython, but because we have this legacy stuff written in C in the stdlib they are put at a disadvantage. It would be better to pool resources and make sure everyone gets to use an equivalent standard library when possible.

And I should also mention I expect the PyPy folks to be the ones to move their code over; I would never expect anyone to re-implement datetime from scratch.
Date User Action Args
2010-06-08 00:58:49brett.cannonsetrecipients: + brett.cannon, lemburg, belopolsky, r.david.murray, brian.curtin, daniel.urban
2010-06-08 00:58:49brett.cannonsetmessageid: <>
2010-06-08 00:58:48brett.cannonlinkissue7989 messages
2010-06-08 00:58:47brett.cannoncreate