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

Clarify the current practices of how to develop a PEP.

This commit is contained in:
Brett Cannon 2010-03-05 03:07:12 +00:00
parent d142f19eb9
commit 12ff0d6e72
1 changed files with 37 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

63
pep-0001.txt
View File

@ -60,17 +60,18 @@ There are three kinds of PEP:
PEP Work Flow
=============
The PEP editors assign PEP numbers and change their status. The
current PEP editors are David Goodger and Barry Warsaw. Please send
The PEP editors assign PEP numbers and change their status. Please send
all PEP-related email to <peps@python.org> (no cross-posting please).
Also see `PEP Editor Responsibilities & Workflow`_ below.
The PEP process begins with a new idea for Python. It is highly
recommended that a single PEP contain a single key proposal or new
idea. The more focussed the PEP, the more successful it tends to
be. The PEP editor reserves the right to reject PEP proposals if they
appear too unfocussed or too broad. If in doubt, split your PEP into
several well-focussed ones.
idea. 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 Python `issue tracker`_. The more focussed the
PEP, the more successful it tends to be. The PEP editor reserves the
right to reject PEP proposals if they appear too unfocussed or too
broad. If in doubt, split your PEP into several well-focussed ones.
Each PEP must have a champion -- someone who writes the PEP using the
style and format described below, shepherds the discussions in the
@ -78,13 +79,31 @@ 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. Posting to the
comp.lang.python newsgroup (a.k.a. python-list@python.org mailing
list) is recommended. 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 Python `issue tracker`_.
list) or the python-ideas mailing list is the best way to go about this.
The PEP champion then emails the PEP editor <peps@python.org> 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.
Vetting an idea publicly before going as far as writing a PEP is meant
to save the potential author time. Many ideas have been brought
forward for changing Python that have been rejected for various
reasons. Asking the Python community first if an idea is original
helps prevent too much time being spent on something that is
guaranteed to be rejected based on prior discussions (searching
the internet does not always do the trick). It also helps to make sure
the idea is applicable to the entire community and not just the author.
Just because an idea sounds good to the author does not
mean it will work for most people in most areas where Python is used.
Once the champion has asked the Python community as to whether an
idea has any chance of acceptance, a draft PEP should be presented to
python-ideas. This gives the author a chance to flesh out the draft
PEP to make properly formatted, of high quality, and to address
initial concerns about the proposal.
Following a discussion on python-ideas, the proposal should be sent to
the `python-dev list <mailto:python-dev@python.org>`__ with the draft
PEP and the PEP editors <peps@python.org>. This
draft must be written in PEP style as described below, else it will be
sent back without further regard until proper formatting rules are
followed.
If the PEP editor approves, he will assign the PEP a number, label it
as Standards Track, Informational, or Process, give it status "Draft",
@ -96,16 +115,9 @@ 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 arbiter 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 updates
are necessary, the PEP author can check in new versions if they have
SVN commit permissions, or can email new PEP versions to the PEP
editor for committing.
As updates are necessary, the PEP author can check in new versions if
they have SVN commit permissions, or can email new PEP versions to
the PEP editor for committing.
Standards Track PEPs consist of two parts, a design document and a
reference implementation. The PEP should be reviewed and accepted
@ -115,10 +127,9 @@ 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
before submitting it for review. 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
for the topic, having the PEP author accept private comments in the
early design phases, setting up a wiki page, etc. PEP authors should