This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients ajaksu2, belopolsky, brett.cannon, doerwalter, eric.araujo, ggenellina, kawai, pitrou, rafe, vstinner
Date 2010-05-26.09:24:06
SpamBayes Score 0.033732634
Marked as misclassified No
Message-id <1274865851.83.0.479687226875.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
> The second is whether we should take this opportunity to fix datetime
> being a C extension module exclusively. I know PyPy has their own pure
> Python version of datetime that they plan to eventually contribute. We 
> might as well use this as the chance to create Lib/datetime.py and have 
> that conditionally import _datetimemodule.c (see the heapq module on 
> how to handle this kind of situation).

Of we could let PyPy contribute their own version when they want, after all.
I think additions to the datetime API are good in themselves, and we shouldn't make them depend on some mythical refactoring of the code into a separate pure Python module ;)
History
Date User Action Args
2010-05-26 09:24:12pitrousetrecipients: + pitrou, doerwalter, brett.cannon, belopolsky, ggenellina, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-05-26 09:24:11pitrousetmessageid: <1274865851.83.0.479687226875.issue5094@psf.upfronthosting.co.za>
2010-05-26 09:24:06pitroulinkissue5094 messages
2010-05-26 09:24:06pitroucreate