[Python-checkins] CVS: python/nondist/peps pep-0001.txt,1.14,1.15

2001年3月21日 09:05:30 -0800

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv4573
Modified Files:
	pep-0001.txt 
Log Message:
Some updates based on feedback from PEP authors. Also, this applies
SF patch #410223 by Andrew Kuchling, describing the new Replaces: and
Replaced-by: headers.
Index: pep-0001.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0001.txt,v
retrieving revision 1.14
retrieving revision 1.15
diff -C2 -r1.14 -r1.15
*** pep-0001.txt	2000年10月30日 21:16:38	1.14
--- pep-0001.txt	2001年03月21日 17:05:27	1.15
***************
*** 7,11 ****
 Type: Informational
 Created: 13-Jun-2000
! Post-History:

--- 7,11 ----
 Type: Informational
 Created: 13-Jun-2000
! Post-History: 21-Mar-2001

***************
*** 38,56 ****

! PEP Workflow

 The PEP editor, Barry Warsaw <barry@digicool.com>, assigns numbers
 for each PEP and changes its status.

! When a new feature is introduced on python-dev, a brief high-level
! discussion should be conducted, not on the merits of the proposal,
! but on whether the idea is significant enough to warrant a PEP.
! Should consensus on PEP-ability be reached, a champion must be
! identified. The champion offers to take the discussion off-line
! and specifies a location (e.g. egroups, python.org, Roundup).

- The champion then emails the PEP editor with a proposed title and
- a rough, but fleshed out, draft of the PEP.
- 
 If the PEP editor approves, he will assign the PEP a number, label
 it as standards track or informational, give it status 'draft',
--- 38,60 ----

! PEP Work Flow

 The PEP editor, Barry Warsaw <barry@digicool.com>, assigns numbers
 for each PEP and changes its status.

! The PEP process begins with a new idea for Python. Each PEP must
! have a champion -- someone who writes the PEP using the style and
! format described below, shepherds the discussions in the
! appropriate forums, and attempts to build community consensus
! around the idea. The PEP champion (a.k.a. Author) should first
! attempt to ascertain whether the idea is PEP-able. Small
! enhancements or patches often don't need a PEP and can be injected
! into the Python development work flow with a patch submission to
! the SourceForge patch manager[2] or feature request tracker[3].
! 
! The PEP champion then emails the PEP editor with a proposed title
! and a rough, but fleshed out, draft of the PEP. This draft must
! be written in PEP style as described below.

 If the PEP editor approves, he will assign the PEP a number, label
 it as standards track or informational, give it status 'draft',
***************
*** 58,87 ****
 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 <guido@python.org>) is the
! final arbitrator of the latter.
! 
! In general, an initial draft of the PEP should be prepared before
! discussion occurs on the python-dev and pyton-list mailing lists.
! The author should incorporate comments and feedback into this
! initial draft when possible.
! 
! The authors of the PEP are then responsible for writing the PEP
! and marshaling community support for it. The structure of a PEP
! is described in detail below. The PEP consists of two parts, a
! design document and a reference implementation. The PEP should be
! reviewed and accepted before a reference implementation is begun,
! unless a reference implementation will aid people in studying the
! PEP. A Standards Track PEP must include an implementation - in
! the form of code, patch, or URL to same - before it can be
! considered Final.

 PEP authors are responsible for collecting community feedback on a
 PEP before submitting it for review. A PEP that has not been
! discussed on python-list and python-dev will not be accepted for
! review. However, wherever possible, long open-ended discussions
! on public mailing lists should be avoided. A better strategy is
! to encourage public feedback directly to the PEP author, who
! collects and integrates the comments back into the PEP.

 Once the authors have completed a PEP, they must inform the PEP
--- 62,92 ----
 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
! <guido@python.org>) 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
! the community forums, and marshaling community support for it. As
! updates are necessary, the PEP author can check in new versions if
! they have CVS commit permissions, or can email new PEP versions to
! the PEP editor for committing.
! 
! Standards track PEPs consists of two parts, a design document and
! a reference implementation. The PEP should be reviewed and
! accepted before a reference implementation is begun, unless a
! reference implementation will aid people in studying the PEP.
! Standards Track PEPs must include an implementation - in the form
! of code, patch, or URL to same - before it can be considered
! Final.

 PEP authors are responsible for collecting community feedback on a
 PEP before submitting it for review. A PEP that has not been
! discussed on python-list@python.org and/or python-dev@python.org
! will not be accepted. However, wherever possible, long open-ended
! discussions on public mailing lists should be avoided. A better
! strategy is to encourage public feedback directly to the PEP
! author, who collects and integrates the comments back into the
! PEP.

 Once the authors have completed a PEP, they must inform the PEP
***************
*** 103,109 ****
 this fact.

 PEP work flow is as follows:

! Draft -> Accepted -> Final
 ^
 +----> Rejected
--- 108,118 ----
 this fact.

+ PEPs can also be replaced by a different PEP, rendering the
+ original obsolete. This is intended for Informational PEPs, where
+ version 2 of an API can replace version 1.
+ 
 PEP work flow is as follows:

! Draft -> Accepted -> Final -> Replaced
 ^
 +----> Rejected
***************
*** 119,134 ****
 Each PEP should have the following parts:

! 1. Title -- a short, descriptive title

! 2. Author(s) -- names and contact info for each author

! 3. Abstract -- a short (~200 word) description of the technical issue
! being addressed
! 
! 4. Copyright/public domain -- Each PEP must either be explicitly
 labelled in the public domain or the Open Publication
! License[2].

! 5. Specification -- The technical specification should describe
 the syntax and semantics of any new language feature. The
 specification should be detailed enough to allow competing,
--- 128,143 ----
 Each PEP should have the following parts:

! 1. Preamble -- RFC822 style headers containing meta-data about the
! PEP, including the PEP number, a short descriptive title, the
! names contact info for each author, etc.

! 2. Abstract -- a short (~200 word) description of the technical
! issue being addressed.

! 3. Copyright/public domain -- Each PEP must either be explicitly
 labelled in the public domain or the Open Publication
! License[4].

! 4. Specification -- The technical specification should describe
 the syntax and semantics of any new language feature. The
 specification should be detailed enough to allow competing,
***************
*** 136,140 ****
 platforms (CPython, JPython, Python .NET).

! 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
--- 145,149 ----
 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
***************
*** 146,151 ****
 during discussion.

! 7. 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
--- 155,160 ----
 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
 to finish the specification and rationale first and reach
***************
*** 161,168 ****
 PEPs are written in plain ASCII text, and should adhere to a
 rigid style. There is a Python script that parses this style and
! converts the plain text PEP to HTML for viewing on the web[3].

! Each PEP begins with an RFC822 style header section. Required
! headers are as follows, and must appear in this order:

 PEP: <pep number>
--- 170,179 ----
 PEPs are written in plain ASCII text, and should adhere to a
 rigid style. There is a Python script that parses this style and
! converts the plain text PEP to HTML for viewing on the web[5].

! Each PEP must begin with an RFC822 style header preamble. The
! headers must appear in the following order. Headers marked with
! `*' are optional and are described below. All other headers are
! required.

 PEP: <pep number>
***************
*** 170,198 ****
 Version: <cvs version string>
 Author: <list of authors' email and real name>
 Status: <Draft | Active | Accepted | Deferred | Final>
 Type: <Informational | Standards Track>
 Created: <date created on, in dd-mmm-yyyy format>
 Post-History: <dates of postings to python-list and python-dev>

! Standards track PEPs should additionally have a Python-Version:
! header which indicates the version of Python that the feature will
! be released with.

 While a PEP is in private discussions (usually during the initial
 Draft phase), a Discussions-To: header will indicate the mailing
! list or URL where the PEP is being discussed.
! 
! PEP headings should begin in column zero and should be
! capitalized. The body of each section should be indented 4
 spaces. Code samples inside body sections should be indented a
 further 4 spaces, and other indentation can be used as required to
! make the text readable. You should use two blank lines between
! the last line of a section's body and the next section heading.

! No tabs should appear in the document at all. A PEP should
! include the Emacs stanza included by example in this PEP to aid
! Emacs editors.

! A PEP must contain a Copyright heading, and it is strongly
 recommended to put the PEP in the public domain.

--- 181,222 ----
 Version: <cvs version string>
 Author: <list of authors' email and real name>
+ * Discussions-To: <email address>
 Status: <Draft | Active | Accepted | Deferred | Final>
 Type: <Informational | Standards Track>
 Created: <date created on, in dd-mmm-yyyy format>
+ * Python-Version: <version number>
 Post-History: <dates of postings to python-list and python-dev>
+ * Replaces: <pep number>
+ * Replaced-By: <pep number>

! Standards track PEPs must have a Python-Version: header which
! indicates the version of Python that the feature will be released
! with. Informational PEPs do not need a Python-Version: header.

 While a PEP is in private discussions (usually during the initial
 Draft phase), a Discussions-To: header will indicate the mailing
! list or URL where the PEP is being discussed. No Discussions-To:
! header is necessary if the PEP is being discussed privately with
! the author, or on the python-list or python-dev email mailing
! lists.
! 
! PEPs may also have a Replaced-By: header indicating that a PEP has
! been rendered obsolete by a later document; the value is the
! number of the PEP that replaces the current document. The newer
! PEP must have a Replaces: header containing the number of the PEP
! that it rendered obsolete.
! 
! PEP headings must begin in column zero and the initial letter of
! each word must be capitalized as in book titles. Acronyms should
! be in all capitals. The body of each section must be indented 4
 spaces. Code samples inside body sections should be indented a
 further 4 spaces, and other indentation can be used as required to
! make the text readable. You must use two blank lines between the
! last line of a section's body and the next section heading.

! Tab characters must never appear in the document at all. A PEP
! should include the Emacs stanza included by example in this PEP.

! A PEP must contain a Copyright section, and it is strongly
 recommended to put the PEP in the public domain.

***************
*** 201,209 ****

- Copyright
- 
- This document has been placed in the public domain.
- 
- 
 References and Footnotes

--- 225,228 ----
***************
*** 214,221 ****

 http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/?cvsroot=python

! [2] http://www.opencontent.org/openpub/

! [3] The script referred to here is pep2html.py, which lives in
 the same directory in the CVS tree as the PEPs themselves. Try
 "pep2html.py --help" for details.
--- 233,244 ----

 http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/?cvsroot=python
+ 
+ [2] http://sourceforge.net/tracker/?group_id=5470&atid=305470

! [3] http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse

! [4] http://www.opencontent.org/openpub/
! 
! [5] The script referred to here is pep2html.py, which lives in
 the same directory in the CVS tree as the PEPs themselves. Try
 "pep2html.py --help" for details.
***************
*** 224,227 ****
--- 247,254 ----
 http://python.sourceforge.net/peps/

+ 
+ Copyright
+ 
+ This document has been placed in the public domain.