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

Brett Cannon brett at python.org
Wed Jul 7 21:32:01 CEST 2010

On Tue, Jul 6, 2010 at 20:54, Terry Reedy <tjreedy at udel.edu> wrote:

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?

The idea is that the stdlib just becomes a subrepo that the other VMs simply pull in to gain their version of the stdlib.

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

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.

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.

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

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. Using ctypes is just added complexity.

 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.

Franke Wierzbicki and I started such a PEP, but we both got busy with other stuff. And since I am most likely going to be the one spearheading this on the CPython side this will most likely not move forward until I have time to get to it (which might be quite a while).

-Brett

-- Terry Jan Reedy

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