Marc-Andre Lemburg <m...@egenix.com> added the comment:
Alexander Belopolsky wrote:
>
> Alexander Belopolsky <belopol...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
