PEP 2, Procedure for Adding New Modules
Martijn Faassen
m.faassen at vet.uu.nl
Sat Mar 9 06:49:47 EST 2002
Hi there,
With all the discussion on the further evolution of Python recently I
decided to dig up my long-dormant proposal for PEP 2, 'Procedure for
Adding New Modules' (to the standard library).
So here it is again, with minor editing. I've also added another open issue
involving the keeping of a list of head maintainers.
I'll also pass it on to Barry so it can be actually included in the index
of proposed PEPs.
Note that currently this PEP stays away from technical issues and focuses on
the organisational aspects of adding a new module and then maintaining it. It
should be supplemented by a PEP detailing the technical procedure, if
necessary (that includes tests and documentation requirements).
Title: Procedure for Adding New Modules
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.
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 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:
- They determine if a proposed contribution should become part of
the standard library.
- They integrate accepted contributions into the standard library.
- They produce standard library releases.
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 frequently is a group
of people such as for instance 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).
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).
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.
This different requirement exists for the following reasons:
- 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.
- 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.
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.
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 always
can 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; checkin privileges,
coding style requirements, documentation requirements, test suite
requirements. These are preferably part of another PEP.
Should the current standard library be subdivided among
maintainers? Many parts already have (informal) maintainers; it
may be good to make this more explicit.
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?
Copyright
This document has been placed in the public domain.
More information about the Python-list
mailing list