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

View File

@ -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.