[Python-Dev] Include datetime.py in stdlib or not?

[Alexander Belopolsky]

This idea has been discussed extensively in this and other forums and
I believe it is time to make a decision.

The proposal is to add pure python implementation of datetime module
to stdlib.   The current C implementation will transparently override
pure python definitions in CPython.  Other python implementations will
have an option of supplying their own fast implementation.  This
approach has already been adopted by several modules including pickle,
heapq and warnings.   It has even been suggested [1] that this is the
direction in which the majority of CPython extension modules should be
heading.

 This proposal has brought mostly positive feedback on the tracker [2]
with only a few objections being raised.

1. Since this does not bring any new functionality and datetime module
is not expected to evolve, there is no need for pure python version.
2. There are other areas of stdlib that can benefit more from pure
python equivalents.
3. Reference implementations should be written by a senior CPython
developer and not scraped from external projects like PyPy.

Let me briefly address these objections:

1. Availability of pure python equivalents of standard library modules
is very helpful for debugging python applications. This is
particularly true when the stdlib module is designed to be extendable
by and calls into user-supplied code.  This is true in the case of
datetime module which relies on 3rd-party or user-supplied code for
any timezone support.

The datetime module indeed saw very little development in the last 6
years.   However this lack of development may itself be the result of
pure python version not being available.  For example, the idea to
supply a concrete tzinfo object representing UTC has been brought up
back in 2002. [3]  An RFE [4] was created in the tracker in January,
2009 and took more than 1.5 years to implement.  If you look at the
history of issue5094, you will see that development slowed down
considerably when C coding started.  Note that for this particular
feature, there was probably no need to have it implemented in C to
begin with.  (Most common operations involve datetime objects in the
same timezone and those don't need to call timezone methods.)

2. Unlike other areas of stdlib, datetime module was originally
prototyped in python and it turns out that it hardly changed between
python 2.3 and 2.6 with a couple of features added in 2.7.  A port to
3.x was uneventful as well.

3. The version of datetime.py [5] that I propose for inclusion is
substantially the pure python prototype written by Tim Peters and
others back in 2003.  The PyPy changes are very few [6].

I believe the code is substantially ready for inclusion.  There are a
few items that need to be fixed related to how floating point
arguments to timedelta are handled, as well as some clean-up of
docstrings and error messages (both C and python implementations can
see some improvement in this area).  The biggest item in terms of
development effort would be to refactor  test_datetime to test both
implementations.  A simple solution [7] of importing test_datetime
twice with and without _datetime will probably not be accepted because
it is not compatible with alternative unittest runners.

What do you think?  Please reply here or add a comment at
http://bugs.python.org/issue7989.

[1] http://bugs.python.org/issue5094#msg106498
[2] http://bugs.python.org/issue7989
[3] http://www.zope.org/Members/fdrake/DateTimeWiki/SuggestedRequirements
[4] http://bugs.python.org/issue5094
[5] http://svn.python.org/view/*checkout*/sandbox/branches/py3k-datetime/datetime.py
[6] http://bugs.python.org/file17701/datetime-sandbox-pypy.diff
[7] http://bugs.python.org/file17848/issue7989.diff