Some clarifications about what should go in a successful PEP, as well
as cause for rejection of pre-PEPs.
This commit is contained in:
parent
aed55275c0
commit
888748d8c8
34
pep-0001.txt
34
pep-0001.txt
|
@ -6,7 +6,7 @@ Author: Barry A. Warsaw, Jeremy Hylton
|
||||||
Status: Active
|
Status: Active
|
||||||
Type: Informational
|
Type: Informational
|
||||||
Created: 13-Jun-2000
|
Created: 13-Jun-2000
|
||||||
Post-History: 21-Mar-2001
|
Post-History: 21-Mar-2001, 29-Jul-2002
|
||||||
|
|
||||||
|
|
||||||
What is a PEP?
|
What is a PEP?
|
||||||
|
@ -69,10 +69,17 @@ PEP Work Flow
|
||||||
and create and check-in the initial draft of the PEP. The PEP
|
and create and check-in the initial draft of the PEP. The PEP
|
||||||
editor will not unreasonably deny a PEP. Reasons for denying PEP
|
editor will not unreasonably deny a PEP. Reasons for denying PEP
|
||||||
status include duplication of effort, being technically unsound,
|
status include duplication of effort, being technically unsound,
|
||||||
or not in keeping with the Python philosophy. The BDFL
|
not providing proper motivation or addressing backwards
|
||||||
(Benevolent Dictator for Life, Guido van Rossum) can be consulted
|
compatibility, or not in keeping with the Python philosophy. The
|
||||||
during the approval phase, and is the final arbitrator of the
|
BDFL (Benevolent Dictator for Life, Guido van Rossum) can be
|
||||||
draft's PEP-ability.
|
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 author of the PEP is then responsible for posting the PEP to
|
||||||
the community forums, and marshaling community support for it. As
|
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
|
interoperable implementations for any of the current Python
|
||||||
platforms (CPython, JPython, Python .NET).
|
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
|
describing what motivated the design and why particular design
|
||||||
decisions were made. It should describe alternate designs that
|
decisions were made. It should describe alternate designs that
|
||||||
were considered and related work, e.g. how the feature is
|
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
|
community and discuss important objections or concerns raised
|
||||||
during discussion.
|
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
|
be completed before any PEP is given status 'Final,' but it
|
||||||
need not be completed before the PEP is accepted. It is better
|
need not be completed before the PEP is accepted. It is better
|
||||||
to finish the specification and rationale first and reach
|
to finish the specification and rationale first and reach
|
||||||
|
|
Loading…
Reference in New Issue