diff --git a/pep-0002.txt b/pep-0002.txt index 0c8e10335..b4c423562 100644 --- a/pep-0002.txt +++ b/pep-0002.txt @@ -5,204 +5,209 @@ Last-Modified: $Date$ Author: Martijn Faassen 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: