[issue7989] Add pure Python implementation of datetime module to CPython

Marc-Andre Lemburg report at bugs.python.org
Thu Jun 17 16:31:35 CEST 2010


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at 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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________


More information about the Python-bugs-list mailing list