diff --git a/pep-0002.txt b/pep-0002.txt index 73928ad1c..0cfbfe179 100644 --- a/pep-0002.txt +++ b/pep-0002.txt @@ -2,212 +2,63 @@ PEP: 2 Title: Procedure for Adding New Modules Version: $Revision$ Last-Modified: $Date$ -Author: Martijn Faassen -Status: Superseded +Author: Brett Cannon , + Martijn Faassen +Status: Active 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]_. - 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. +It is therefore important that the usefulness of the standard library +be maintained. -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. +Due to the visibility and importance of the standard library, it must +be maintained thoughtfully. As such, any code within it must be +maintained by Python's development team which leads to a perpetual +cost to each addition made. There is also added cognitive load for +users in familiarizing themselves with what is in the standard +library to be considered. 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). +For top-level modules/packages, a PEP is required. The procedure for +writing a PEP is covered in :pep:`1`. -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. +For submodules of a preexisting package in the standard library, +additions are at the discretion of the general Python development team +and its members. -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. +General guidance on what modules typically are accepted into the +standard library, the overall process, etc. are covered in the +`developer's guide `_. 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. +Anything accepted into the standard library is expected to be +primarily maintained there, within Python's development infrastructure. +While some members of the development team may choose to maintain a +backport of a module outside of the standard library, it is up to them +to keep their external code in sync as appropriate. -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. - -.. - Local Variables: - mode: indented-text - indent-tabs-mode: nil - fill-column: 70 - coding: utf-8 - End: diff --git a/pep-0004.txt b/pep-0004.txt index d0b636250..68b980031 100644 --- a/pep-0004.txt +++ b/pep-0004.txt @@ -24,298 +24,20 @@ At the same time, removing a module from the distribution is difficult, as it is not known in general whether anybody is still using it. This PEP defines a procedure for removing modules from the standard Python library. Usage of a module may be 'deprecated', which -means that it may be removed from a future Python release. The -rationale for deprecating a module is also collected in this PEP. If -the rationale turns out faulty, the module may become 'undeprecated'. +means that it may be removed from a future Python release. Procedure for declaring a module deprecated =========================================== -Since the status of module deprecation is recorded in this PEP, -proposals for deprecating modules MUST be made by providing a change -to the text of this PEP. +To remove a top-level module/package from the standard library, a PEP +is required. The deprecation process is outlined in :pep:`387`. -A proposal for deprecation of the module MUST include the date of the -proposed deprecation and a rationale for deprecating it. In addition, -the proposal MUST include a change to the documentation of the module; -deprecation is indicated by saying that the module is "obsolete" or -"deprecated". The proposal SHOULD include a patch for the module's -source code to indicate deprecation there as well, by raising a -DeprecationWarning. The proposal MUST include patches to remove any -use of the deprecated module from the standard library. - -It is expected that deprecated modules are included in the Python -release that immediately follows the deprecation; later releases may -ship without the deprecated modules. - - -For modules existing in both Python 2.7 and Python 3.5 ------------------------------------------------------- - -In order to facilitate writing code that works in both Python 2 & 3 -simultaneously, any module that exists in both Python 3.5 and -Python 2.7 will not be removed from the standard library until -Python 2.7 is no longer supported as specified by :pep:`373`. Exempted -from this rule is any module in the idlelib package as well as any -exceptions granted by the Python development team. - - -Procedure for declaring a module undeprecated -============================================= - -When a module becomes deprecated, a rationale is given for its -deprecation. In some cases, an alternative interface for the same -functionality is provided, so the old interface is deprecated. In -other cases, the need for having the functionality of the module may -not exist anymore. - -If the rationale is faulty, again a change to this PEP's text MUST be -submitted. This change MUST include the date of undeprecation and a -rationale for undeprecation. Modules that are undeprecated under this -procedure MUST be listed in this PEP for at least one major release of -Python. - - -Obsolete modules -================ - -A number of modules are already listed as obsolete in the library -documentation. These are listed here for completeness. - - cl, sv, timing - -All these modules have been declared as obsolete in Python 2.0, some -even earlier. - -The following obsolete modules were removed in Python 2.5: - - addpack, cmp, cmpcache, codehack, dircmp, dump, find, fmt, - grep, lockfile, newdir, ni, packmail, Para, poly, - rand, reconvert, regex, regsub, statcache, tb, tzparse, - util, whatsound, whrandom, zmod - -The following modules were removed in Python 2.6: - - gopherlib, rgbimg, macfs - -The following modules currently lack a DeprecationWarning: - - rfc822, mimetools, multifile - - -Deprecated modules -================== - -:: - - Module name: posixfile - Rationale: Locking is better done by fcntl.lockf(). - Date: Before 1-Oct-2000. - Documentation: Already documented as obsolete. Deprecation - warning added in Python 2.6. - - Module name: gopherlib - Rationale: The gopher protocol is not in active use anymore. - Date: 1-Oct-2000. - Documentation: Documented as deprecated since Python 2.5. Removed - in Python 2.6. - - Module name: rgbimgmodule - Rationale: In a 2001-04-24 c.l.py post, Jason Petrone mentions - that he occasionally uses it; no other references to - its use can be found as of 2003-11-19. - Date: 1-Oct-2000 - Documentation: Documented as deprecated since Python 2.5. Removed - in Python 2.6. - - Module name: pre - Rationale: The underlying PCRE engine doesn't support Unicode, and - has been unmaintained since Python 1.5.2. - Date: 10-Apr-2002 - Documentation: It was only mentioned as an implementation detail, - and never had a section of its own. This mention - has now been removed. - - Module name: whrandom - Rationale: The module's default seed computation was - inherently insecure; the random module should be - used instead. - Date: 11-Apr-2002 - Documentation: This module has been documented as obsolete since - Python 2.1, but listing in this PEP was neglected. - The deprecation warning will be added to the module - one year after Python 2.3 is released, and the - module will be removed one year after that. - - Module name: rfc822 - Rationale: Supplanted by Python 2.2's email package. - Date: 18-Mar-2002 - Documentation: Documented as "deprecated since release 2.3" since - Python 2.2.2. - - Module name: mimetools - Rationale: Supplanted by Python 2.2's email package. - Date: 18-Mar-2002 - Documentation: Documented as "deprecated since release 2.3" since - Python 2.2.2. - - Module name: MimeWriter - Rationale: Supplanted by Python 2.2's email package. - Date: 18-Mar-2002 - Documentation: Documented as "deprecated since release 2.3" since - Python 2.2.2. Raises a DeprecationWarning as of - Python 2.6. - - Module name: mimify - Rationale: Supplanted by Python 2.2's email package. - Date: 18-Mar-2002 - Documentation: Documented as "deprecated since release 2.3" since - Python 2.2.2. Raises a DeprecationWarning as of - Python 2.6. - - Module name: rotor - Rationale: Uses insecure algorithm. - Date: 24-Apr-2003 - Documentation: The documentation has been removed from the library - reference in Python 2.4. - - Module name: TERMIOS.py - Rationale: The constants in this file are now in the 'termios' module. - Date: 10-Aug-2004 - Documentation: This module has been documented as obsolete since - Python 2.1, but listing in this PEP was neglected. - Removed from the library reference in Python 2.4. - - Module name: statcache - Rationale: Using the cache can be fragile and error-prone; - applications should just use os.stat() directly. - Date: 10-Aug-2004 - Documentation: This module has been documented as obsolete since - Python 2.2, but listing in this PEP was neglected. - Removed from the library reference in Python 2.5. - - Module name: mpz - Rationale: Third-party packages provide similar features - and wrap more of GMP's API. - Date: 10-Aug-2004 - Documentation: This module has been documented as obsolete since - Python 2.2, but listing in this PEP was neglected. - Removed from the library reference in Python 2.4. - - Module name: xreadlines - Rationale: Using 'for line in file', introduced in 2.3, is preferable. - Date: 10-Aug-2004 - Documentation: This module has been documented as obsolete since - Python 2.3, but listing in this PEP was neglected. - Removed from the library reference in Python 2.4. - - Module name: multifile - Rationale: Supplanted by the email package. - Date: 21-Feb-2006 - Documentation: Documented as deprecated as of Python 2.5. - - Module name: sets - Rationale: The built-in set/frozenset types, introduced in - Python 2.4, supplant the module. - Date: 12-Jan-2007 - Documentation: Documented as deprecated as of Python 2.6. - - Module name: buildtools - Rationale: Unknown. - Date: 15-May-2007 - Documentation: Documented as deprecated as of Python 2.3, but - listing in this PEP was neglected. Raised a - DeprecationWarning as of Python 2.6. - - Module name: cfmfile - Rationale: Unknown. - Date: 15-May-2007 - Documentation: Documented as deprecated as of Python 2.4, but - listing in this PEP was neglected. A - DeprecationWarning was added in Python 2.6. - - Module name: macfs - Rationale: Unknown. - Date: 15-May-2007 - Documentation: Documented as deprecated as of Python 2.3, but - listing in this PEP was neglected. Removed in - Python 2.6. - - Module name: md5 - Rationale: Replaced by the 'hashlib' module. - Date: 15-May-2007 - Documentation: Documented as deprecated as of Python 2.5, but - listing in this PEP was neglected. - DeprecationWarning raised as of Python 2.6. - - Module name: sha - Rationale: Replaced by the 'hashlib' module. - Date: 15-May-2007 - Documentation: Documented as deprecated as of Python 2.5, but - listing in this PEP was neglected. - DeprecationWarning added in Python 2.6. - - Module name: plat-freebsd2/IN and plat-freebsd3/IN - Rationale: Platforms are obsolete (last released in 2000) - Removed from 2.6 - Date: 15-May-2007 - Documentation: None - - Module name: plat-freebsd4/IN and possibly plat-freebsd5/IN - Rationale: Platforms are obsolete/unsupported - Date: 15-May-2007 - Remove from 2.7 - Documentation: None - - Module name: imp - Rationale: Replaced by the importlib module. - Date: 2013-02-10 - Documentation: Deprecated as of Python 3.4. - - Module name: formatter - Rationale: Lack of use in the community, no tests to keep - code working. - Date: 2013-08-12 - Documentation: Deprecated as of Python 3.4. - - Module name: macpath - Rationale: Obsolete macpath module dangerously broken - and should be removed. - Date: 2017-05-15 - Documentation: Platform is obsolete/unsupported. - - Module name: xml.etree.cElementTree - Rationale: Obsolete, use xml.etree.ElementTree - Date: 2019-04-06 - Documentation: Documented as deprecated since 3.3 - -Deprecation of modules removed in Python 3.0 -============================================ - -:pep:`3108` lists all modules that have been removed from Python 3.0. -They all are documented as deprecated in Python 2.6, and raise a -DeprecationWarning if the -3 flag is activated. - - -Undeprecated modules -==================== - -None. +For removing a submodule of a package in the standard library, +:pep:`387` must be followed, but a PEP is not required. Copyright ========= This document has been placed in the public domain. - - - -.. - Local Variables: - mode: indented-text - indent-tabs-mode: nil - sentence-end-double-space: t - fill-column: 70 - coding: utf-8 - End: diff --git a/pep-0411.txt b/pep-0411.txt index 77ef98f19..8bee39e6b 100644 --- a/pep-0411.txt +++ b/pep-0411.txt @@ -4,13 +4,21 @@ Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan , Eli Bendersky -Status: Active +Status: Superseded Type: Informational Content-Type: text/x-rst Created: 10-Feb-2012 Python-Version: 3.3 Post-History: 10-Feb-2012, 24-Mar-2012 +.. note:: + + This PEP has been marked as *Superseded*. A decade after this PEP + was written, experience has shown this is a rarely used feature in + managing the standard library. It has also not helped prevent + people from relying too heavily on provisional modules, such that + changes can still cause significant breakage in the community. + Abstract ======== @@ -199,13 +207,3 @@ Copyright ========= This document has been placed in the public domain. - - -.. - Local Variables: - mode: indented-text - indent-tabs-mode: nil - sentence-end-double-space: t - fill-column: 70 - coding: utf-8 - End: