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.

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.

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 it is frequently a group of people such as the XML- SIG. Groups may subdivide maintenance tasks among themselves. One or 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 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 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?

References

[1]

Adding to the Stdlib (http://docs.python.org/devguide/stdlibchanges.html)

Copyright

This document has been placed in the public domain.