Convert PEP 2 to reST format
This commit is contained in:
Matthias Bussonnier
Berker Peksag
parent
6929f850a5
commit
cce5754f28
293
pep-0002.txt
293
pep-0002.txt
|
|
@ -5,204 +5,209 @@ Last-Modified: $Date$
|
|||
Author: Martijn Faassen <faassen@infrae.com>
|
||||
Status: Final
|
||||
Type: Process
|
||||
Content-Type: text/x-rst
|
||||
Created: 07-Jul-2001
|
||||
Post-History: 07-Jul-2001, 09-Mar-2002
|
||||
|
||||
|
||||
PEP Replacement
|
||||
|
||||
This PEP has been superseded by the updated material in the Python
|
||||
Developer's Guide [1].
|
||||
PEP Replacement
|
||||
===============
|
||||
|
||||
This PEP has been superseded by the updated material in the Python
|
||||
Developer's Guide [1]_.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
The Python Standard Library contributes significantly to Python's
|
||||
success. The language comes with "batteries included", so it is
|
||||
easy for people to become productive with just the standard
|
||||
library alone. It is therefore important that this library grows
|
||||
with the language, and that such growth is supported and
|
||||
encouraged.
|
||||
The Python Standard Library contributes significantly to Python's
|
||||
success. The language comes with "batteries included", so it is easy
|
||||
for people to become productive with just the standard library alone.
|
||||
It is therefore important that this library grows with the language,
|
||||
and that such growth is supported and encouraged.
|
||||
|
||||
Many contributions to the library are not created by core
|
||||
developers but by people from the Python community who are experts
|
||||
in their particular field. Furthermore, community members are
|
||||
also the users of the standard library, applying it in a great
|
||||
diversity of settings. This makes the community well equipped to
|
||||
detect and report gaps in the library; things that are missing but
|
||||
should be added.
|
||||
Many contributions to the library are not created by core developers
|
||||
but by people from the Python community who are experts in their
|
||||
particular field. Furthermore, community members are also the users of
|
||||
the standard library, applying it in a great diversity of settings.
|
||||
This makes the community well equipped to detect and report gaps in
|
||||
the library; things that are missing but should be added.
|
||||
|
||||
New functionality is commonly added to the library in the form of new
|
||||
modules. This PEP will describe the procedure for the *addition* of
|
||||
new modules. PEP 4 deals with procedures for deprecation of modules;
|
||||
the *removal* of old and unused modules from the standard library.
|
||||
Finally there is also the issue of *changing* existing modules to make
|
||||
the picture of library evolution complete. PEP 3 and PEP 5 give some
|
||||
guidelines on this. The continued maintenance of existing modules is
|
||||
an integral part of the decision on whether to add a new module to the
|
||||
standard library. Therefore, this PEP also introduces concepts
|
||||
(integrators, maintainers) relevant to the maintenance issue.
|
||||
|
||||
New functionality is commonly added to the library in the form of
|
||||
new modules. This PEP will describe the procedure for the
|
||||
_addition_ of new modules. PEP 4 deals with procedures for
|
||||
deprecation of modules; the _removal_ of old and unused modules
|
||||
from the standard library. Finally there is also the issue of
|
||||
_changing_ existing modules to make the picture of library
|
||||
evolution complete. PEP 3 and PEP 5 give some guidelines on this.
|
||||
The continued maintenance of existing modules is an integral part
|
||||
of the decision on whether to add a new module to the standard
|
||||
library. Therefore, this PEP also introduces concepts
|
||||
(integrators, maintainers) relevant to the maintenance issue.
|
||||
|
||||
|
||||
Integrators
|
||||
===========
|
||||
|
||||
The integrators are a group of people with the following
|
||||
responsibilities:
|
||||
The integrators are a group of people with the following
|
||||
responsibilities:
|
||||
|
||||
- They determine if a proposed contribution should become part of
|
||||
the standard library.
|
||||
* They determine if a proposed contribution should become part of the
|
||||
standard library.
|
||||
|
||||
- They integrate accepted contributions into the standard library.
|
||||
* They integrate accepted contributions into the standard library.
|
||||
|
||||
- They produce standard library releases.
|
||||
* They produce standard library releases.
|
||||
|
||||
This group of people shall be PythonLabs, led by Guido.
|
||||
This group of people shall be PythonLabs, led by Guido.
|
||||
|
||||
|
||||
Maintainer(s)
|
||||
=============
|
||||
|
||||
All contributions to the standard library need one or more
|
||||
maintainers. This can be an individual, but it is frequently a
|
||||
group of people such as the XML-SIG. Groups may subdivide
|
||||
maintenance tasks among themselves. One ore more maintainers
|
||||
shall be the _head maintainer_ (usually this is also the main
|
||||
developer). Head maintainers are convenient people the
|
||||
integrators can address if they want to resolve specific issues,
|
||||
such as the ones detailed later in this document.
|
||||
All contributions to the standard library need one or more
|
||||
maintainers. This can be an individual, but it is frequently a group
|
||||
of people such as the XML- SIG. Groups may subdivide maintenance
|
||||
tasks among themselves. One ore more maintainers shall be the *head
|
||||
maintainer* (usually this is also the main developer). Head
|
||||
maintainers are convenient people the integrators can address if they
|
||||
want to resolve specific issues, such as the ones detailed later in
|
||||
this document.
|
||||
|
||||
|
||||
Developers(s)
|
||||
=============
|
||||
|
||||
Contributions to the standard library have been developed by one
|
||||
or more developers. The initial maintainers are the original
|
||||
developers unless there are special circumstances (which should be
|
||||
detailed in the PEP proposing the contribution).
|
||||
Contributions to the standard library have been developed by one or
|
||||
more developers. The initial maintainers are the original developers
|
||||
unless there are special circumstances (which should be detailed in
|
||||
the PEP proposing the contribution).
|
||||
|
||||
|
||||
Acceptance Procedure
|
||||
====================
|
||||
|
||||
When developers wish to have a contribution accepted into the
|
||||
standard library, they will first form a group of maintainers
|
||||
(normally initially consisting of themselves).
|
||||
When developers wish to have a contribution accepted into the standard
|
||||
library, they will first form a group of maintainers (normally
|
||||
initially consisting of themselves).
|
||||
|
||||
Then, this group shall produce a PEP called a library PEP. A
|
||||
library PEP is a special form of standards track PEP. The library
|
||||
PEP gives an overview of the proposed contribution, along with the
|
||||
proposed contribution as the reference implementation. This PEP
|
||||
should also contain a motivation on why this contribution should
|
||||
be part of the standard library.
|
||||
Then, this group shall produce a PEP called a library PEP. A library
|
||||
PEP is a special form of standards track PEP. The library PEP gives
|
||||
an overview of the proposed contribution, along with the proposed
|
||||
contribution as the reference implementation. This PEP should also
|
||||
contain a motivation on why this contribution should be part of the
|
||||
standard library.
|
||||
|
||||
One or more maintainers shall step forward as PEP champion (the
|
||||
people listed in the Author field are the champions). The PEP
|
||||
champion(s) shall be the initial head maintainer(s).
|
||||
|
||||
As described in PEP 1, a standards track PEP should consist of a
|
||||
design document and a reference implementation. The library PEP
|
||||
differs from a normal standard track PEP in that the reference
|
||||
implementation should in this case always already have been
|
||||
written before the PEP is to be reviewed for inclusion by the
|
||||
integrators and to be commented upon by the community; the
|
||||
reference implementation _is_ the proposed contribution.
|
||||
One or more maintainers shall step forward as PEP champion (the people
|
||||
listed in the Author field are the champions). The PEP champion(s)
|
||||
shall be the initial head maintainer(s).
|
||||
|
||||
This different requirement exists for the following reasons:
|
||||
As described in PEP 1, a standards track PEP should consist of a
|
||||
design document and a reference implementation. The library PEP
|
||||
differs from a normal standard track PEP in that the reference
|
||||
implementation should in this case always already have been written
|
||||
before the PEP is to be reviewed for inclusion by the integrators and
|
||||
to be commented upon by the community; the reference implementation
|
||||
*is* the proposed contribution.
|
||||
|
||||
- The integrators can only properly evaluate a contribution to the
|
||||
standard library when there is source code and documentation to
|
||||
look at; i.e. the reference implementation is always necessary
|
||||
to aid people in studying the PEP.
|
||||
This different requirement exists for the following reasons:
|
||||
|
||||
- Even rejected contributions will be useful outside the standard
|
||||
library, so there will a lower risk of waste of effort by the
|
||||
developers.
|
||||
|
||||
- It will impress the integrators of the seriousness of
|
||||
contribution and will help guard them against having to evaluate
|
||||
too many frivolous proposals.
|
||||
* The integrators can only properly evaluate a contribution to the
|
||||
standard library when there is source code and documentation to look
|
||||
at; i.e. the reference implementation is always necessary to aid
|
||||
people in studying the PEP.
|
||||
|
||||
Once the library PEP has been submitted for review, the
|
||||
integrators will then evaluate it. The PEP will follow the normal
|
||||
PEP work flow as described in PEP 1. If the PEP is accepted, they
|
||||
will work through the head maintainers to make the contribution
|
||||
ready for integration.
|
||||
* Even rejected contributions will be useful outside the standard
|
||||
library, so there will a lower risk of waste of effort by the
|
||||
developers.
|
||||
|
||||
* It will impress the integrators of the seriousness of contribution
|
||||
and will help guard them against having to evaluate too many
|
||||
frivolous proposals.
|
||||
|
||||
Once the library PEP has been submitted for review, the integrators
|
||||
will then evaluate it. The PEP will follow the normal PEP work flow
|
||||
as described in PEP 1. If the PEP is accepted, they will work through
|
||||
the head maintainers to make the contribution ready for integration.
|
||||
|
||||
|
||||
Maintenance Procedure
|
||||
=====================
|
||||
|
||||
After a contribution has been accepted, the job is not over for
|
||||
both integrators and maintainers. The integrators will forward
|
||||
any bug reports in the standard library to the appropriate head
|
||||
maintainers.
|
||||
After a contribution has been accepted, the job is not over for both
|
||||
integrators and maintainers. The integrators will forward any bug
|
||||
reports in the standard library to the appropriate head maintainers.
|
||||
|
||||
Before the feature freeze preparing for a release of the standard
|
||||
library, the integrators will check with the head maintainers for
|
||||
all contributions, to see if there are any updates to be included
|
||||
in the next release. The integrators will evaluate any such
|
||||
updates for issues like backwards compatibility and may require
|
||||
PEPs if the changes are deemed to be large.
|
||||
Before the feature freeze preparing for a release of the standard
|
||||
library, the integrators will check with the head maintainers for all
|
||||
contributions, to see if there are any updates to be included in the
|
||||
next release. The integrators will evaluate any such updates for
|
||||
issues like backwards compatibility and may require PEPs if the
|
||||
changes are deemed to be large.
|
||||
|
||||
The head maintainers should take an active role in keeping up to
|
||||
date with the Python development process. If a head maintainer is
|
||||
unable to function in this way, he or she should announce the
|
||||
intention to step down to the integrators and the rest of the
|
||||
maintainers, so that a replacement can step forward. The
|
||||
integrators should at all times be capable of reaching the head
|
||||
maintainers by email.
|
||||
The head maintainers should take an active role in keeping up to date
|
||||
with the Python development process. If a head maintainer is unable
|
||||
to function in this way, he or she should announce the intention to
|
||||
step down to the integrators and the rest of the maintainers, so that
|
||||
a replacement can step forward. The integrators should at all times
|
||||
be capable of reaching the head maintainers by email.
|
||||
|
||||
In the case where no head maintainer can be found (possibly
|
||||
because there are no maintainers left), the integrators will issue
|
||||
a call to the community at large asking for new maintainers to
|
||||
step forward. If no one does, the integrators can decide to
|
||||
declare the contribution deprecated as described in PEP 4.
|
||||
In the case where no head maintainer can be found (possibly because
|
||||
there are no maintainers left), the integrators will issue a call to
|
||||
the community at large asking for new maintainers to step forward. If
|
||||
no one does, the integrators can decide to declare the contribution
|
||||
deprecated as described in PEP 4.
|
||||
|
||||
|
||||
Open issues
|
||||
===========
|
||||
|
||||
There needs to be some procedure so that the integrators can
|
||||
always reach the maintainers (or at least the head maintainers).
|
||||
This could be accomplished by a mailing list to which all head
|
||||
maintainers should be subscribed (this could be python-dev).
|
||||
Another possibility, which may be useful in any case, is the
|
||||
maintenance of a list similar to that of the list of PEPs which
|
||||
lists all the contributions and their head maintainers with
|
||||
contact info. This could in fact be part of the list of the PEPs,
|
||||
as a new contribution requires a PEP. But since the
|
||||
authors/owners of a PEP introducing a new module may eventually be
|
||||
different from those who maintain it, this wouldn't resolve all
|
||||
issues yet.
|
||||
There needs to be some procedure so that the integrators can always
|
||||
reach the maintainers (or at least the head maintainers). This could
|
||||
be accomplished by a mailing list to which all head maintainers should
|
||||
be subscribed (this could be python-dev). Another possibility, which
|
||||
may be useful in any case, is the maintenance of a list similar to
|
||||
that of the list of PEPs which lists all the contributions and their
|
||||
head maintainers with contact info. This could in fact be part of the
|
||||
list of the PEPs, as a new contribution requires a PEP. But since the
|
||||
authors/owners of a PEP introducing a new module may eventually be
|
||||
different from those who maintain it, this wouldn't resolve all issues
|
||||
yet.
|
||||
|
||||
Should there be a list of what criteria integrators use for
|
||||
evaluating contributions? (Source code but also things like
|
||||
documentation and a test suite, as well as such vague things like
|
||||
'dependability of the maintainers'.)
|
||||
|
||||
This relates to all the technical issues; check-in privileges,
|
||||
coding style requirements, documentation requirements, test suite
|
||||
requirements. These are preferably part of another PEP.
|
||||
Should there be a list of what criteria integrators use for evaluating
|
||||
contributions? (Source code but also things like documentation and a
|
||||
test suite, as well as such vague things like 'dependability of the
|
||||
maintainers'.)
|
||||
|
||||
Should the current standard library be subdivided among
|
||||
maintainers? Many parts already have (informal) maintainers; it
|
||||
may be good to make this more explicit.
|
||||
This relates to all the technical issues; check-in privileges, coding
|
||||
style requirements, documentation requirements, test suite
|
||||
requirements. These are preferably part of another PEP.
|
||||
|
||||
Perhaps there is a better word for 'contribution'; the word
|
||||
'contribution' may not imply enough that the process (of
|
||||
development and maintenance) does not stop after the contribution
|
||||
is accepted and integrated into the library.
|
||||
Should the current standard library be subdivided among maintainers?
|
||||
Many parts already have (informal) maintainers; it may be good to make
|
||||
this more explicit.
|
||||
|
||||
Relationship to the mythical Catalog?
|
||||
Perhaps there is a better word for 'contribution'; the word
|
||||
'contribution' may not imply enough that the process (of development
|
||||
and maintenance) does not stop after the contribution is accepted and
|
||||
integrated into the library.
|
||||
|
||||
Relationship to the mythical Catalog?
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] Adding to the Stdlib
|
||||
http://docs.python.org/devguide/stdlibchanges.html
|
||||
.. [1] Adding to the Stdlib
|
||||
(http://docs.python.org/devguide/stdlibchanges.html)
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
||||
This document has been placed in the public domain.
|
||||
This document has been placed in the public domain.
|
||||
|
||||
|
||||
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
fill-column: 70
|
||||
End:
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
fill-column: 70
|
||||
coding: utf-8
|
||||
End:
|
||||
|
|
|
|||
Loading…
Reference in New Issue