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: