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

Spellchecked.

This commit is contained in:
Barry Warsaw 2012-05-17 06:53:13 -04:00
parent 6dee3b79b2
commit f5e3789b13
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
pep-0001.txt
View File

@ -42,7 +42,7 @@ There are three kinds of PEP:
provides general guidelines or information to the Python community, provides general guidelines or information to the Python community,
but does not propose a new feature. Informational PEPs do not but does not propose a new feature. Informational PEPs do not
necessarily represent a Python community consensus or necessarily represent a Python community consensus or
recommendation, so users and implementors are free to ignore recommendation, so users and implementers are free to ignore
Informational PEPs or follow their advice. Informational PEPs or follow their advice.
3. A **Process** PEP describes a process surrounding Python, or 3. A **Process** PEP describes a process surrounding Python, or
@ -81,10 +81,10 @@ 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 recommended that a single PEP contain a single key proposal or new
idea. Small enhancements or patches often don't need idea. Small enhancements or patches often don't need
a PEP and can be injected into the Python development work flow with a 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 patch submission to the Python `issue tracker`_. The more focused the
PEP, the more successful it tends to be. The PEP editor reserves 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 right to reject PEP proposals if they appear too unfocused or too
broad. If in doubt, split your PEP into several well-focussed ones. broad. If in doubt, split your PEP into several well-focused ones.
Each PEP must have a champion -- someone who writes the PEP using the Each PEP must have a champion -- someone who writes the PEP using the
style and format described below, shepherds the discussions in the style and format described below, shepherds the discussions in the
@ -164,7 +164,7 @@ PEP Review & Resolution
Once the authors have completed a PEP, they must inform the PEP editors Once the authors have completed a PEP, they must inform the PEP editors
that it is ready for review. PEPs are reviewed by the BDFL and his that it is ready for review. PEPs are reviewed by the BDFL and his
chosen consultants, who may accept or reject a PEP or send it back to chosen consultants, who may accept or reject a PEP or send it back to
the author(s) for revision. For a PEP that is pre-determined to be the author(s) for revision. For a PEP that is predetermined to be
acceptable (e.g., it is an obvious win as-is and/or its implementation acceptable (e.g., it is an obvious win as-is and/or its implementation
has already been checked in) the BDFL may also initiate a PEP review, has already been checked in) the BDFL may also initiate a PEP review,
first notifying the PEP author(s) and giving them a chance to make first notifying the PEP author(s) and giving them a chance to make
@ -232,7 +232,7 @@ PEP Maintenance
In general, Standards track PEPs are no longer modified after they have In general, Standards track PEPs are no longer modified after they have
reached the Final state. Once a PEP has been completed, the Language and reached the Final state. Once a PEP has been completed, the Language and
Standard Library References become the formal documentation of the expected Standard Library References become the formal documentation of the expected
behaviour. behavior.
Informational and Process PEPs may be updated over time to reflect changes Informational and Process PEPs may be updated over time to reflect changes
to development practices and other details. The precise process followed in to development practices and other details. The precise process followed in
@ -254,7 +254,7 @@ Each PEP should have the following parts:
being addressed. being addressed.
3. Copyright/public domain -- Each PEP must either be explicitly 3. Copyright/public domain -- Each PEP must either be explicitly
labelled as placed in the public domain (see this PEP as an labeled as placed in the public domain (see this PEP as an
example) or licensed under the `Open Publication License`_. example) or licensed under the `Open Publication License`_.
4. Specification -- The technical specification should describe the 4. Specification -- The technical specification should describe the
@ -515,7 +515,7 @@ to the Python codebase. The PEP editors monitor the python-checkins
list for PEP changes, and correct any structure, grammar, spelling, or list for PEP changes, and correct any structure, grammar, spelling, or
markup mistakes we see. markup mistakes we see.
The editors don't pass judgement on PEPs. We merely do the The editors don't pass judgment on PEPs. We merely do the
administrative & editorial part. Except for times like this, there's administrative & editorial part. Except for times like this, there's
relatively low volume. relatively low volume.