[Python-Dev] Include datetime.py in stdlib or not? (original) (raw)

Brett Cannon brett at python.org
Tue Jul 6 22:30:00 CEST 2010

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  testdatetime to test both implementations.  A simple solution [7] of importing testdatetime 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

More information about the Python-Dev mailing list