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

Terry Reedy tjreedy at udel.edu
Wed Jul 7 05:54:25 CEST 2010

On 7/6/2010 3:59 PM, Alexander Belopolsky wrote:

I am more interested in Brett's overall vision than this particular module. I understand that to be one of a stdlib that is separate from CPython and is indeed the standard Python library.

Questions:

!. Would the other distributions use a standard stdlib rather than current individual versions? If so, and if at least one used the Python version of each module, this would alleviate the concern that non-use == non-testing. (Test improvement would also help this.)

  1. Would the other distributions pool their currently separate stdlib efforts to help maintain one standard stdlib. If so, this would alleviate the concern about the extra effort to maintain both a C and Python version. (Test improvement would also help this also.)

  2. What version of Python would be allowed for use in the stdlib? I would like the stdlib for 3.x to be able to use 3.x code. This would be only a minor concern for CPython as long as 2.7 is maintained, but a major concern for the other implementation currently 'stuck' in 2.x only. A good 3to2 would be needed.

I generally favor having Python versions of modules available. My current post on difflib.SequenceMatcher is based on experiments with an altered version. I copied difflib.py to my test directory, renamed it diff2lib.py, so I could import both versions, found and edited the appropriate method, and off I went. If difflib were in C, my post would have been based on speculation about how a fixed version would operate, rather than on data.

  1. Does not ctypes make it possible to replace a method of a Python-coded class with a faster C version, with something like try: connect to methods.dll check that function xyx exists replace Someclass.xyy with ctypes wrapper except: pass For instance, the SequenceMatcher heuristic was added to speedup the matching process that I believe is encapsulated in one O(n**2) or so bottleneck method. I believe most everything else is O(n) bookkeeping.

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.

see above

2. There are other areas of stdlib that can benefit more from pure python equivalents.

Possibly true, but developers do what they do, and this seems mostly done.

3. Reference implementations should be written by a senior CPython developer and not scraped from external projects like PyPy.

I did not see that im my reading of the thread. In any case, what matters is quality, not authorship.

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

From scanning that and the posts here, it seems like a pep or other doc on dual version modules would be a good idea. It should at least document how to code the switch from python version to the x coded version and how to test both, as discussed.

-- Terry Jan Reedy

More information about the Python-Dev mailing list