Message108019
| 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? |
|