iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEPs 2, 4, 411: updates to how the stdlib is managed (#2651) 

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
This commit is contained in:
Brett Cannon 2022-09-23 15:56:29 -07:00 committed by GitHub
parent 90ae6434f6
commit 565cc9cd94
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 38 additions and 467 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

197
pep-0002.txt
View File

@ -2,212 +2,63 @@ PEP: 2
Title: Procedure for Adding New Modules
Version: $Revision$
Last-Modified: $Date$
Author: Martijn Faassen <faassen@infrae.com>
Status: Superseded
Author: Brett Cannon <brett@python.org>,
Martijn Faassen <faassen@infrae.com>
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 <https://devguide.python.org/stdlibchanges/>`_.
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:

288
pep-0004.txt
View File

@ -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:

20
pep-0411.txt
View File

@ -4,13 +4,21 @@ Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan <ncoghlan@gmail.com>,
Eli Bendersky <eliben@gmail.com>
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: