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

Jesse Noller jnoller at gmail.com
Wed Jul 7 17:43:34 CEST 2010

On Wed, Jul 7, 2010 at 11:29 AM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:

On Tue, Jul 6, 2010 at 11:54 PM, 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. I am also very much interested in the overall vision, but I would like to keep the datetime.py thread focused, so I a going to reply to broad questions under a separate subject. Questions: 1. Would the other distributions use a standard stdlib rather than current individual versions? I certainly hope they will.  In the ideal word, passing test.regrtest with unmodified Lib should be the definition of what is called Python.  I understand that there is already some work underway in this direction such as marking implementation specific tests with appropriate decorators.

2. Would the other distributions pool their currently separate stdlib efforts to help maintain one standard stdlib? I believe that making stdlib and test.regrtest more friendly to alternative implementations will go long way towards this goal.  It will, of course, be a decision that each project will have to make. 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. Availability of python equivalents will hopefully help  "other implementation currently 'stuck' in 2.x only" to get "unstuck" and move to 3.x.   I understand that this is a somewhat sensitive issue at the moment, but I believe a decision has been made supporting new features for 2.x is outside of python-dev focus.

[the rest snipped for now]

I agree with Alexander's responses. Brett can chime in here too, and so can Frank W. or any of the other people who were involved in the conversation. Essentially, many of us agreed "one stdlib to bind them", from a canonical repository would help everyone involved. Any modules which were specific to the implementation - such as multiprocessing would either be flagged as such or not included in the shared repo (TBD).

This effort has been on hold largely due to the fact we're waiting on the mercurial migration. It's not something I think any of us would want to do prior to that, and requires a fair amount of scaffolding / build tools /etc to make it a net win.

Below, you will find the partially completed draft PEP (from a private mercurial repo) Brett/Frank and I had worked on (but again, paused due to mercurial/etc). Now that we're edging closer to 3.2 (this would not happen before then) and mercurial, I think we might need to find the time to finish the PEP:

PEP: XXXX Title: Making the Standard Library a Separate Project Version: Revision:65628Revision: 65628 Revision:65628 Last-Modified: Date:2008−08−1006:59:20−0700(Sun,10Aug2008)Date: 2008-08-10 06:59:20 -0700 (Sun, 10 Aug 2008) Date:2008−08−1006:59:20−0700(Sun,10Aug2008) Author: XXX Status: Draft Type: Process Content-Type: text/x-rst Created: 14-Aug-2009 Post-History:

.. warning:: This PEP will not be submitted until the migration of CPython to Mercurial occurs.

Abstract

XXX

Rationale

Although the C implementation of Python (CPython) is the original and reference implementation of the Python language, there are now a number of additional implementations that are widely used and reasonably complete implementations. Among these implementations are Jython_, IronPython_, and PyPy_.

At PyCon 2009_, representatives of multiple implementations of Python agreed that it would be a good idea to divide the Python Standard Library into two logical components, the first being a shared library that is essential for an implementation of Python to be considered a full implementation. All Python implementations would share this library on equal terms. The second library would be an implementation-specific standard library for things that are either implementation details for a specific VM or that depend on internals of each implementation (for example, if part of the implementation must be written in C for CPython or written in Java for Jython).

The test suite should be similarly exposed and shared between all implementations on equal terms: one set of tests that must pass to be considered a full implementation, and one set of implementation-specific tests layered on top of the shared test suite (think garbage collection vs refcounting, etc). The same pattern should apply to documentation as well.

The idea is to put CPython on a more equal footing with the other implementations, and to remove the need to have Jython, IronPython or PyPy specific cases in the CPython standard library.

Criteria for Inclusion/Exclusion of Code

To be included in the shared library, a module must have a pure Python implementation. If the module also has a native implementation, the identical unit tests must pass in both the pure and native versions. The modules must not use any features that are considered implementation-dependent, and must only depend on other modules within the shared library unless specifically listed below (whose tests are included in the shared library):

XXX: need to specify the subsets of the sys and os module that are required. XXX: also include modules that have no pure Python implementation but are still expected to be included (e.g. datetime)

Modules

XXX: maybe we shouldn't list all the modules to include but instead only the module to exclude; list is rather long and only listed what to remove gets the point across that most things will make the transition

Modules to Exclude ''''''''''''''''''

XXX Python 2.6 or 2.7?

Intra-Module Objects to Exclude '''''''''''''''''''''''''''''''

XXX E.g. sys._getframe()

Documentation Notation

XXX How to document a module is CPython-specific in Sphinx

Documentation

XXX Language docs, shared library, PEPs

Code Layout

XXX

Copyright

This document has been placed in the public domain.

.. _Jython: http://www.jython.org./ .. _IronPython: http://www.codeplex.com/IronPython .. _PyPy: http://codespeak.net/pypy/ .. _PyCon 2009: http://us.pycon.org/2009/about/

.. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

jesse

More information about the Python-Dev mailing list