[Python-checkins] python/nondist/peps pep-0001.txt,1.35,1.36
bwarsaw@users.sourceforge.net
bwarsaw@users.sourceforge.net
Mon, 29 Jul 2002 11:35:01 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv10014
Modified Files:
pep-0001.txt
Log Message:
Some clarifications about what should go in a successful PEP, as well
as cause for rejection of pre-PEPs.
Index: pep-0001.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0001.txt,v
retrieving revision 1.35
retrieving revision 1.36
diff -C2 -d -r1.35 -r1.36
*** pep-0001.txt 12 Jul 2002 16:39:49 -0000 1.35
--- pep-0001.txt 29 Jul 2002 18:34:59 -0000 1.36
***************
*** 7,11 ****
Type: Informational
Created: 13-Jun-2000
! Post-History: 21-Mar-2001
--- 7,11 ----
Type: Informational
Created: 13-Jun-2000
! Post-History: 21-Mar-2001, 29-Jul-2002
***************
*** 70,77 ****
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.
The author of the PEP is then responsible for posting the PEP to
--- 70,84 ----
editor will not unreasonably deny a PEP. Reasons for denying PEP
status include duplication of effort, being technically unsound,
! 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
***************
*** 155,159 ****
platforms (CPython, JPython, Python .NET).
! 5. 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
--- 162,172 ----
platforms (CPython, JPython, Python .NET).
! 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
***************
*** 165,169 ****
during discussion.
! 6. 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
--- 178,189 ----
during discussion.
! 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