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

Some clarifications about what should go in a successful PEP, as well 

as cause for rejection of pre-PEPs.
This commit is contained in:
Barry Warsaw 2002-07-29 18:34:59 +00:00
parent aed55275c0
commit 888748d8c8
1 changed files with 27 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
pep-0001.txt
View File

@ -6,7 +6,7 @@ Author: Barry A. Warsaw, Jeremy Hylton
Status: Active
Type: Informational
Created: 13-Jun-2000
Post-History: 21-Mar-2001
Post-History: 21-Mar-2001, 29-Jul-2002
What is a PEP?
@ -69,10 +69,17 @@ PEP Work Flow
and create and check-in the initial draft of the PEP. The PEP
editor will not unreasonably deny a PEP. Reasons for denying PEP
status include duplication of effort, being technically unsound,
or not in keeping with the Python philosophy. The BDFL
(Benevolent Dictator for Life, Guido van Rossum) can be consulted
during the approval phase, and is the final arbitrator of the
draft's PEP-ability.
not providing proper motivation or addressing backwards
compatibility, or not in keeping with the Python philosophy. The
BDFL (Benevolent Dictator for Life, Guido van Rossum) can be
consulted during the approval phase, and is the final arbitrator
of the draft's PEP-ability.
If a pre-PEP is rejected, the author may elect to take the pre-PEP
to the comp.lang.python newsgroup (a.k.a. python-list@python.org
mailing list) to help flesh it out, gain feedback and consensus
from the community at large, and improve the PEP for
re-submission.
The author of the PEP is then responsible for posting the PEP to
the community forums, and marshaling community support for it. As
@ -154,7 +161,13 @@ What belongs in a successful PEP?
interoperable implementations for any of the current Python
platforms (CPython, JPython, Python .NET).
5. Rationale -- The rationale fleshes out the specification by
5. Motivation -- The motivation is critical for PEPs that want to
change the Python language. It should clearly explain why the
existing language specification is inadequate to address the
problem that the PEP solves. PEP submissions without
sufficient motivation may be rejected outright.
6. Rationale -- The rationale fleshes out the specification by
describing what motivated the design and why particular design
decisions were made. It should describe alternate designs that
were considered and related work, e.g. how the feature is
@ -164,7 +177,14 @@ What belongs in a successful PEP?
community and discuss important objections or concerns raised
during discussion.
6. Reference Implementation -- The reference implementation must
7. Backwards Compatibility -- All PEPs that introduce backwards
incompatibilities must include a section describing these
incompatibilities and their severity. The PEP must explain how
the author proposes to deal with these incompatibilities. PEP
submissions without a sufficient backwards compatibility
treatise may be rejected outright.
8. Reference Implementation -- The reference implementation must
be completed before any PEP is given status 'Final,' but it
need not be completed before the PEP is accepted. It is better
to finish the specification and rationale first and reach