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

[Terry Reedy]

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.)

2. 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.)

3. 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.

4. 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