[Python-checkins] python/nondist/peps pep-0001.txt,1.37,1.38
bwarsaw@users.sourceforge.net
bwarsaw@users.sourceforge.net
Mon, 26 Aug 2002 09:19:28 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv14219
Modified Files:
pep-0001.txt
Log Message:
David Goodger writes:
* Changed the "PEP Template" section to "PEP Formats and Templates",
in which plaintext and reStructuredText PEPs are described.
* Added "PEP Header Preamble" heading, for the RFC 2822 header
description.
- Rearranged some descriptions to match the header order.
- Removed the colons from header field names (e.g., "the Author
header").
- Added a description of the Content-Type header.
* Moved the plaintext-PEP-specific "PEP Formatting Requirements"
section to PEP 9. PEP 1 now deals only with content, not format.
* Minor edits, including:
- Capitalized "Standards Track" and "Informational" throughout.
- In "it's not like such decisions can be reversed", "can" should be
"can't"; fixed.
Index: pep-0001.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0001.txt,v
retrieving revision 1.37
retrieving revision 1.38
diff -C2 -d -r1.37 -r1.38
*** pep-0001.txt 30 Jul 2002 16:23:15 -0000 1.37
--- pep-0001.txt 26 Aug 2002 16:19:25 -0000 1.38
***************
*** 6,9 ****
--- 6,10 ----
Status: Active
Type: Informational
+ Content-Type: text/plain
Created: 13-Jun-2000
Post-History: 21-Mar-2001, 29-Jul-2002
***************
*** 24,41 ****
community and documenting dissenting opinions.
! Because the PEPs are maintained as plain text files under CVS
! control, their revision history is the historical record of the
! feature proposal[1].
!
Kinds of PEPs
! There are two kinds of PEPs. A standards track PEP describes a
! new feature or implementation for Python. An informational PEP
describes a Python design issue, or provides general guidelines or
information to the Python community, but does not propose a new
feature. Informational PEPs do not necessarily represent a Python
community consensus or recommendation, so users and implementors
! are free to ignore informational PEPs or follow their advice.
--- 25,42 ----
community and documenting dissenting opinions.
! Because the PEPs are maintained as text files under CVS control,
! their revision history is the historical record of the feature
! proposal[1].
!
Kinds of PEPs
! There are two kinds of PEPs. A Standards Track PEP describes a
! new feature or implementation for Python. An Informational PEP
describes a Python design issue, or provides general guidelines or
information to the Python community, but does not propose a new
feature. Informational PEPs do not necessarily represent a Python
community consensus or recommendation, so users and implementors
! are free to ignore Informational PEPs or follow their advice.
***************
*** 66,70 ****
If the PEP editor approves, he will assign the PEP a number, label
! it as standards track or informational, give it status 'draft',
and create and check-in the initial draft of the PEP. The PEP
editor will not unreasonably deny a PEP. Reasons for denying PEP
--- 67,71 ----
If the PEP editor approves, he will assign the PEP a number, label
! it as Standards Track or Informational, give it status "Draft",
and create and check-in the initial draft of the PEP. The PEP
editor will not unreasonably deny a PEP. Reasons for denying PEP
***************
*** 88,92 ****
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
--- 89,93 ----
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
***************
*** 113,124 ****
Once a PEP has been accepted, the reference implementation must be
completed. When the reference implementation is complete and
! accepted by the BDFL, the status will be changed to `Final.'
! A PEP can also be assigned status `Deferred.' The PEP author or
editor can assign the PEP this status when no progress is being
made on the PEP. Once a PEP is deferred, the PEP editor can
re-assign it to draft status.
! A PEP can also be `Rejected'. Perhaps after all is said and done
it was not a good idea. It is still important to have a record of
this fact.
--- 114,125 ----
Once a PEP has been accepted, the reference implementation must be
completed. When the reference implementation is complete and
! accepted by the BDFL, the status will be changed to "Final".
! A PEP can also be assigned status "Deferred". The PEP author or
editor can assign the PEP this status when no progress is being
made on the PEP. Once a PEP is deferred, the PEP editor can
re-assign it to draft status.
! A PEP can also be "Rejected". Perhaps after all is said and done
it was not a good idea. It is still important to have a record of
this fact.
***************
*** 136,140 ****
Deferred
! Some informational PEPs may also have a status of `Active' if they
are never meant to be completed. E.g. PEP 1.
--- 137,141 ----
Deferred
! Some Informational PEPs may also have a status of "Active" if they
are never meant to be completed. E.g. PEP 1.
***************
*** 186,190 ****
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
--- 187,191 ----
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
***************
*** 196,210 ****
! PEP Template
! 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].
! PEP 9 contains a boilerplate[7] template you can use to get
! started writing your PEP.
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.
--- 197,227 ----
! PEP Formats and Templates
! There are two PEP formats available to authors: plaintext and
! reStructuredText.
!
! Plaintext PEPs are written in plain ASCII text, contain minimal
! structural markup, and should adhere to a rigid style. PEP 9
! contains a boilerplate template[7] you can use to get started
! writing your plaintext PEP.
!
! ReStructuredText PEPs allow for rich markup that is still quite
! easy to read, but results in much better-looking and more
! functional HTML. PEP 12 contains a boilerplate template[8] for
! use with reStructuredText PEPs.
!
! There is a Python script that converts both styles of PEPs to HTML
! for viewing on the web[5]. Parsing and conversion of plaintext
! PEPs is self-contained within the script. reStructuredText PEPs
! are parsed and converted by Docutils[9] code called from the
! script.
!
!
! PEP Header Preamble
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.
***************
*** 217,220 ****
--- 234,238 ----
Status: <Draft | Active | Accepted | Deferred | Final | Replaced>
Type: <Informational | Standards Track>
+ * Content-Type: <text/plain | text/x-rst>
* Requires: <pep numbers>
Created: <date created on, in dd-mmm-yyyy format>
***************
*** 224,230 ****
* Replaced-By: <pep number>
! The Author: header lists the names, and optionally the email
addresses of all the authors/owners of the PEP. The format of the
! author entry must be
Random J. User <address@dom.ain>
--- 242,248 ----
* Replaced-By: <pep number>
! The Author header lists the names, and optionally the email
addresses of all the authors/owners of the PEP. The format of the
! Author header value must be
Random J. User <address@dom.ain>
***************
*** 237,241 ****
"address@dom.ain (Random J. User)" may appear in a PEP, however
new PEPs must use the mandated format above, and it is acceptable
! to change this format when PEPs are updated.
If there are multiple authors, each should be on a separate line
--- 255,259 ----
"address@dom.ain (Random J. User)" may appear in a PEP, however
new PEPs must use the mandated format above, and it is acceptable
! to change to this format when PEPs are updated.
If there are multiple authors, each should be on a separate line
***************
*** 244,332 ****
against spam harvesters.
- 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. Note that email addresses in the Discussions-To: header
will not be obscured.
! Created: records the date that the PEP was assigned a number,
! while Post-History: is used to record the dates of when new
versions of the PEP are posted to python-list and/or python-dev.
Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001.
! PEPs may have a Requires: header, indicating the PEP numbers that
! this PEP depends on.
! 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 Formatting Requirements
-
- 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.
-
- You must adhere to the Emacs convention of adding two spaces at
- the end of every sentence. You should fill your paragraphs to
- column 70, but under no circumstances should your lines extend
- past column 79. If your code samples spill over column 79, you
- should rewrite them.
-
- Tab characters must never appear in the document at all. A PEP
- should include the standard Emacs stanza included by example at
- the bottom of this PEP.
-
- A PEP must contain a Copyright section, and it is strongly
- recommended to put the PEP in the public domain.
-
- When referencing an external web page in the body of a PEP, you
- should include the title of the page in the text, with a
- footnote reference to the URL. Do not include the URL in the body
- text of the PEP. E.g.
-
- Refer to the Python Language web site [1] for more details.
- ...
- [1] http://www.python.org
-
- When referring to another PEP, include the PEP number in the body
- text, such as "PEP 1". The title may optionally appear. Add a
- footnote reference that includes the PEP's title and author. It
- may optionally include the explicit URL on a separate line, but
- only in the References section. Note that the pep2html.py script
- will calculate URLs automatically, e.g.:
-
- ...
- Refer to PEP 1 [7] for more information about PEP style
- ...
-
- References
-
- [7] PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton
- http://www.python.org/peps/pep-0001.html
-
- If you decide to provide an explicit URL for a PEP, please use
- this as the URL template:
-
- http://www.python.org/peps/pep-xxxx.html
-
- PEP numbers in URLs must be padded with zeros from the left, so as
- to be exactly 4 characters wide, however PEP numbers in text are
- never padded.
-
-
Reporting PEP Bugs, or Submitting PEP Updates
--- 262,301 ----
against spam harvesters.
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. Note that email addresses in the Discussions-To header
will not be obscured.
! The Type header specifies the type of PEP: Informational or
! Standards Track.
!
! The format of a PEP is specified with a Content-Type header. The
! acceptable values are "text/plain" for plaintext PEPs (see PEP 9
! [7]) and "text/x-rst" for reStructuredText PEPs (see PEP 12 [8]).
! Plaintext ("text/plain") is the default if no Content-Type header
! is present.
!
! The Created header records the date that the PEP was assigned a
! number, while Post-History is used to record the dates of when new
versions of the PEP are posted to python-list and/or python-dev.
Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001.
! 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.
! PEPs may have a Requires header, indicating the PEP numbers
! that this PEP depends on.
!
! 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.
Reporting PEP Bugs, or Submitting PEP Updates
***************
*** 373,382 ****
always submit a competing PEP.
! If you are interested assuming ownership of a PEP, send a message
! asking to take over, addressed to both the original author and the
! PEP editor <peps@python.org>. If the original author doesn't
! respond to email in a timely manner, the PEP editor will make a
! unilateral decision (it's not like such decisions can be
! reversed. :).
--- 342,351 ----
always submit a competing PEP.
! If you are interested in assuming ownership of a PEP, send a
! message asking to take over, addressed to both the original author
! and the PEP editor <peps@python.org>. If the original author
! doesn't respond to email in a timely manner, the PEP editor will
! make a unilateral decision (it's not like such decisions can't be
! reversed :).
***************
*** 405,410 ****
[6] http://sourceforge.net/tracker/?group_id=5470&atid=305470
! [7] PEP 9, Sample PEP Template
http://www.python.org/peps/pep-0009.html
--- 374,384 ----
[6] http://sourceforge.net/tracker/?group_id=5470&atid=305470
! [7] PEP 9, Sample Plaintext PEP Template, Warsaw
http://www.python.org/peps/pep-0009.html
+
+ [8] PEP 12, Sample reStructuredText PEP Template, Goodger, Warsaw
+ http://www.python.org/peps/pep-0009.html
+
+ [9] http://docutils.sourceforge.net/