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

[Jesse Noller]

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: 65628 $
Last-Modified: $Date: 2008-08-10 06:59:20 -0700 (Sun, 10 Aug 2008) $
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)

* sys
* os

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