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

[Terry Reedy]

On 7/7/2010 3:32 PM, Brett Cannon wrote:

> That's the idea. We already have contributors from the various VMs who
> has commit privileges, but they all work in their own repos for
> convenience. My hope is that if we break the stdlib out into its own
> repository that people simply pull in then other VM contributors will
> work directly off of the stdlib repo instead of their own, magnifying
> the usefulness of their work.

I was wondering if you had more than 'hope', but thinking about it now, 
I think it premature to ask for commitments. Once a Python3 stdlib hg 
subrepository is set up and running, the logic of joining in should be 
obvious -- or not.

I am now seeing that a more complete common Python-level test suite is 
also important. Being able to move Python code, that only uses the 
stdlibk,between implementations and have it just work would be good for 
all of them.

>> 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.
>
> This will only affect py3k.

Good. The Python3 stdlib should gradually become modern Python3 code. 
(An example archaism -- the use in difflib of dicts with arbitrary 
values used as sets -- which I plan to fix.)

>> 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.
>>
>
> The effect upon CPython would be the extension modules become just
> performance improvements, nothing more (unless they have to be in C as
> in the case for sqlite3).

As pre- and jit compilation improve, the need for hand-coded C will go 
down. For instance, annotate (in a branch, not trunk) and compile with 
Cython.

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

> There is no need to go that far. All one needs to do is structure the
> extension code such that when the extension module is imported, it
> overrides key objects in the Python version.

Is it possible to replace a python-coded function in a python-coded 
class with a C-coded function? I had the impression from the issue 
discussion that one would have to recode the entire class, even if only 
a single method really needed it.

> Using ctypes is just added complexity.

Only to be used if easier than extra C coding.

-- 
Terry Jan Reedy