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