From 888748d8c8ff544752f50232e7ea89ece8f01b96 Mon Sep 17 00:00:00 2001 From: Barry Warsaw Date: Mon, 29 Jul 2002 18:34:59 +0000 Subject: [PATCH] Some clarifications about what should go in a successful PEP, as well as cause for rejection of pre-PEPs. --- pep-0001.txt | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/pep-0001.txt b/pep-0001.txt index 792770ccd..9c32d5360 100644 --- a/pep-0001.txt +++ b/pep-0001.txt @@ -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