Alexander Belopolsky wrote:
>
> Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment:
>
> 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?
That approached was used for modules where the C bits replaced the Python
ones. The Python bites were then typically removed altogether.
To avoid the wasted memory and import time, it's better to use:
try:
from _cmodule import *
except ImportError:
from _pymodule import *
> 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?
Why not import the two modules directly ?
import _cmodule as module
and
import _pymodule as module