On Fri, Aug 6, 2010 at 3:44 AM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
..
> Why are you calling the ticket "*Add* pure Python implementation of time
> module to CPython" when you appear to be after *replacing* the C
> implementation of the time module with a Python version ?
>

I have deliberately made the title similar to issue 7989 so that it is
clear that the idea is the same: add python implementations of time
module functions which are overridden by existing C implementations in
CPython.  The only difference with datetime is that for Python
implementation to work, it needs access to some system facilities. The
datetime.py module needs access to some of these facilities as well,
but currently it works around this problem by importing them from time
module.

The current situation has several problems:

1. Datetime.py time source (time.time()) represents time as a floating
point number which leads to system dependent behavior and introduces
floating point operations where they are not needed.

2. Datetime.strftime function is restricted to years >= 1900 even on
platforms where system strftime is perfectly good over full range of
datetime. This is done expressly because semantics of time.strftime
dictate such behavior.  See issue 1777412.

3. The datetime module could benefit from access to tm_zone and
tm_gmtoff components of the tm structure, but introducing those in the
output of time.localtime() would require either hidden member hackery
or loss of backwards compatibility.  See issues #1647654, #7662, and
#9527.

> The same argument as for the datetime module applies: you can *add*
> a compatible Python version of the same module for other Python
> implementations to use, but undoing the work that has been done
> in order to provide a faster implementation of the Python version
> is a no-go.
>

I completely agree.  Actually my outline in the first post is
incomplete.  What I would like to do is:

1. Rename timemodule.c to _timemodule.c
2. Convert non-module _time.c (home of code shared between time and
datetime C implementations) to a proper C extension.  See issue 9012,
msg109221 for description of the problem with the current strategy.
For luck of better name, I'll call the resulting module _basictime, so
 _time.c will get renamed to _basictimemodule.c.
3. Make _basictime module expose C and Python API to basic time
facilities: integer-valued time sources (gettimeofday, clock, etc.),
integer-based sleep method (say nanosleep), thin wrappers around
system strftime and strptime functions and tzset method.
4. No changes will be done to timemodule.c other than renaming. The
new time.py will import _basictime to implement it's methods in
python, but will end with from _time import *.  The _time module will
not depend on _basictime.
5. In the future, but not as a part of this proposal, datetime C and
python implementations can start using _basictime for low level access
rather than time.

> Both datetime and time module functionalities need to be as fast as
> possible, since they are used a lot in Python code. That was the
> main reason for having a C implementation of the datetime and time
> modules.
>

Absolutely.  In fact this proposal will open the door to implementing
*faster* C API to basic time facilities.  I do want _basictime to
properly expose its C API similarly to the way datetime module already
does.   The current situation is somewhat cheating: datetime module
advertises fast C API, but under the hood imports time module and
makes python calls to its methods.

BTW, this brings a point that I think I missed when I introduced
datetime.py.  Should PyDateTime_CAPSULE_NAME be changed from
"datetime.datetime_CAPI" to  "_datetime.datetime_CAPI" in order to
eliminate even small overhead that loading datetime rather than
_datetime carries?

> Python C function calls are still a lot faster than Python function
> calls. You can't just replace a C function call with a Python one
> without taking this into account. For these modules, it's not just
> the API compatibility that matters, performance is just as
> relevant and I don't really see a point in making CPython slower
> just to make maintenance of stdlib modules that are not needed by
> CPython easier.

Brett addressed this point responding to my own concerns in msg107295
and msg108047.  I will just repeat: this proposal will make no changes
to the functions that CPython users will import from time module.