Spellchecked.
This commit is contained in:
parent
6dee3b79b2
commit
f5e3789b13
16
pep-0001.txt
16
pep-0001.txt
|
@ -42,7 +42,7 @@ There are three kinds of PEP:
|
|||
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
|
||||
recommendation, so users and implementers are free to ignore
|
||||
Informational PEPs or follow their advice.
|
||||
|
||||
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
|
||||
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
|
||||
patch submission to the Python `issue tracker`_. The more focused 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.
|
||||
right to reject PEP proposals if they appear too unfocused or too
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
|
@ -232,7 +232,7 @@ PEP Maintenance
|
|||
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
|
||||
Standard Library References become the formal documentation of the expected
|
||||
behaviour.
|
||||
behavior.
|
||||
|
||||
Informational and Process PEPs may be updated over time to reflect changes
|
||||
to development practices and other details. The precise process followed in
|
||||
|
@ -254,7 +254,7 @@ Each PEP should have the following parts:
|
|||
being addressed.
|
||||
|
||||
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`_.
|
||||
|
||||
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
|
||||
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
|
||||
relatively low volume.
|
||||
|
||||
|
|
Loading…
Reference in New Issue