iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

added new Process PEP type

This commit is contained in:
David Goodger 2005-08-13 01:37:32 +00:00
parent df670b9e4e
commit 7435767028
2 changed files with 58 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
pep-0000.txt
View File

@ -30,7 +30,7 @@ Index by Category
Meta-PEPs (PEPs about PEPs or Process)
I 0 Index of Python Enhancement Proposals Goodger, Warsaw
I 1 PEP Guidelines Warsaw, Hylton, Goodger
P 1 PEP Guidelines Warsaw, Hylton, Goodger
I 2 Procedure for Adding New Modules Faassen
I 3 Guidelines for Handling Bug Reports Hylton
I 4 Deprecation of Standard Modules von Loewis
@ -103,7 +103,7 @@ Index by Category
S 341 Unifying try-except and try-finally Birkenfeld
S 344 Exception Chaining and Embedded Tracebacks Yee
S 345 Metadata for Python Software Packages 1.2 Jones
I 347 Migrating the Python CVS to Subversion von Löwis
P 347 Migrating the Python CVS to Subversion von Löwis
S 348 Exception Reorganization for Python 3.0 Cannon
S 349 Generalized String Coercion Schemenauer
S 754 IEEE 754 Floating Point Special Values Warnes
@ -225,7 +225,7 @@ Numerical Index
num title owner
--- ----- -----
I 0 Index of Python Enhancement Proposals Goodger, Warsaw
I 1 PEP Guidelines Warsaw, Hylton, Goodger
P 1 PEP Guidelines Warsaw, Hylton, Goodger
I 2 Procedure for Adding New Modules Faassen
I 3 Guidelines for Handling Bug Reports Hylton
I 4 Deprecation of Standard Modules von Loewis
@ -391,7 +391,7 @@ Numerical Index
S 344 Exception Chaining and Embedded Tracebacks Yee
S 345 Metadata for Python Software Packages 1.2 Jones
SR 346 User Defined ("with") Statements Coghlan
I 347 Migrating the Python CVS to Subversion von Löwis
P 347 Migrating the Python CVS to Subversion von Löwis
S 348 Exception Reorganization for Python 3.0 Cannon
S 349 Generalized String Coercion Schemenauer
SR 666 Reject Foolish Indentation Creighton
@ -401,8 +401,10 @@ Numerical Index
Key
I - Informational PEP
S - Standards Track PEP
I - Informational PEP
P - Process PEP
A - Accepted proposal
R - Rejected proposal
D - Deferred proposal

87
pep-0001.txt
View File

@ -4,7 +4,7 @@ Version: $Revision$
Last-Modified: $Date$
Author: Barry A. Warsaw, Jeremy Hylton, David Goodger
Status: Active
Type: Informational
Type: Process
Content-Type: text/x-rst
Created: 13-Jun-2000
Post-History: 21-Mar-2001, 29-Jul-2002, 03-May-2003
@ -15,8 +15,9 @@ What is a PEP?
PEP stands for Python Enhancement Proposal. A PEP is a design
document providing information to the Python community, or describing
a new feature for Python. The PEP should provide a concise technical
specification of the feature and a rationale for the feature.
a new feature for Python or its processes or environment. The PEP
should provide a concise technical specification of the feature and a
rationale for the feature.
We intend PEPs to be the primary mechanisms for proposing new
features, for collecting community input on an issue, and for
@ -29,16 +30,31 @@ revision history is the historical record of the feature proposal
[1]_.
Kinds of PEPs
=============
PEP Types
=========
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.
There are three kinds of PEP:
1. A **Standards Track** PEP describes a new feature or implementation
for Python.
2. 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.
3. A **Process** PEP describes a process surrounding Python, or
proposes a change to (or an event in) a process. Process PEPs are
like Standards Track PEPs but apply to areas other than the Python
language itself. They may propose an implementation, but not to
Python's codebase; they often require community consensus; unlike
Informational PEPs, they are more than recommendations, and users
are typically not free to ignore them. Examples include release
schedules, procedures, guidelines, changes to the decision-making
process, and changes to the tools or environment used in Python
development.
PEP Work Flow
@ -71,14 +87,17 @@ 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", 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, 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.
as Standards Track, Informational, or Process, 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 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.
arbiter?
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
@ -91,22 +110,22 @@ 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
Standards Track PEPs consist 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.
PEPs must include an implementation -- in the form of code, a patch,
or a 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. Strategies to keep the
discussions efficient include, setting up a separate SIG mailing list
discussions efficient include: setting up a separate SIG mailing list
for the topic, having the PEP author accept private comments in the
early design phases, etc. PEP authors should use their discretion
here.
early design phases, setting up a wiki page, etc. PEP authors should
use their discretion here.
Once the authors have completed a PEP, they must inform the PEP editor
that it is ready for review. PEPs are reviewed by the BDFL and his
@ -144,13 +163,9 @@ 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::
PEP work flow is as follows:
Draft -> Accepted -> Final -> Replaced
^
+----> Rejected
v
Deferred
.. image:: pep-0001-1.png
Some Informational PEPs may also have a status of "Active" if they are
never meant to be completed. E.g. PEP 1 (this PEP).
@ -250,7 +265,7 @@ optional and are described below. All other headers are required. ::
* Discussions-To: <email address>
Status: <Draft | Active | Accepted | Deferred | Rejected |
Final | Replaced>
Type: <Informational | Standards Track>
Type: <Standards Track | Informational | Process>
* Content-Type: <text/plain | text/x-rst>
* Requires: <pep numbers>
Created: <date created on, in dd-mmm-yyyy format>
@ -286,8 +301,8 @@ 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 Type header specifies the type of PEP: Standards Track,
Informational, or Process.
The format of a PEP is specified with a Content-Type header. The
acceptable values are "text/plain" for plaintext PEPs (see PEP 9 [3]_)
@ -302,7 +317,7 @@ 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.
Informational and Process PEPs do not need a Python-Version header.
PEPs may have a Requires header, indicating the PEP numbers that this
PEP depends on.