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

[Brett Cannon]

On Tue, Jul 6, 2010 at 12:59, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> 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.

I should mention that PyPy has said they are quite happy to donate
their datetime implementation which is what Alexander (I believe) has
been working off of.

Also, adding a pure Python version alleviates the need of the other
VMs from having to maintain the same module separately. Making the
stdlib shareable (and thus eventually breaking it out from CPython)
was discussed at the language summit at PyCon 2010 and generally
agreed upon, and this is a step towards making that happen.

-Brett


>
> 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>