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 belopolsky
Recipients amaury.forgeotdarc, belopolsky, brett.cannon, brian.curtin, daniel.urban, lemburg, r.david.murray, techtonik, vstinner
Date 2010-06-17.14:24:22
SpamBayes Score 0.001058054
Marked as misclassified No
Message-id <1276784665.96.0.495097984522.issue7989@psf.upfronthosting.co.za>
In-reply-to
Content
I would like to move this forward.  The PyPy implementation at

http://codespeak.net/pypy/dist/pypy/lib/datetime.py

claims to be based on the original CPython datetime implementation from the time when datetime was a python module.  I looked through the code and it seems to be very similar to datetime.c.  Some docstings and comments are literal copies.  I think it will not be hard to port that to 3.x.

I have a few questions, though.

1. I remember seeing python-dev discussion that concluded that the best way to distribute parallel C and Python implementations was to have module.py with the following:

# pure python implementation

def foo():
    pass

def bar():
    pass

# ..

try:
    from _module import *
except ImportError:
    pass

Is this still the state of the art?  What about parsing overhead?

2. Is there a standard mechanism to ensure that unitests run both python and C code?  I believe sys.module['_module'] = None will prevent importing _module.  Is there direct regrtest support for this?
History
Date User Action Args
2010-06-17 14:24:26belopolskysetrecipients: + belopolsky, lemburg, brett.cannon, amaury.forgeotdarc, vstinner, techtonik, r.david.murray, brian.curtin, daniel.urban
2010-06-17 14:24:25belopolskysetmessageid: <1276784665.96.0.495097984522.issue7989@psf.upfronthosting.co.za>
2010-06-17 14:24:24belopolskylinkissue7989 messages
2010-06-17 14:24:23belopolskycreate