[Python-checkins] peps: Spellchecked.

[barry.warsaw]

http://hg.python.org/peps/rev/f257aa2796bd
changeset:   4401:f257aa2796bd
user:        Barry Warsaw <barry at python.org>
date:        Thu May 17 06:53:13 2012 -0400
summary:
  Spellchecked.

files:
  pep-0001.txt |  16 ++++++++--------
  1 files changed, 8 insertions(+), 8 deletions(-)


diff --git a/pep-0001.txt b/pep-0001.txt
--- a/pep-0001.txt
+++ b/pep-0001.txt
@@ -42,7 +42,7 @@
    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 @@
 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 @@
 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 @@
 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 @@
    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 @@
 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.
 

-- 
Repository URL: http://hg.python.org/peps