Fix typos

pep-0101.txt

@@ -534,20 +534,20 @@ the main repo.
     #    **new branch** release, i.e. alphas and first beta
     #   do a checkout of the master branch
     $ git checkout master
-    
+
     # 2. Else, for all other releases, checkout the
     #       appropriate release branch.
     $ git checkout X.Y
-    
+
     # Fetch the newly created and signed tag from your clone repo
     $ git fetch --tags git@github.com:your-github-id/cpython.git vX.Y.ZaN
-    # Merge the temporary release engineering branch back into 
+    # Merge the temporary release engineering branch back into
     $ git merge --no-squash vX.Y.ZaN
     $ git commit -m 'Merge release engineering branch'
 
 - If this is a **new branch** release, i.e. first beta,
   now create the new release branch::
- 
+
     $ git checkout -b X.Y
 
 - For *all* releases, do the guided post-release steps with the
@@ -556,7 +556,7 @@ the main repo.
     $ .../release-tools/release.py --done X.Y.ZaN
 
 - Review and commit these changes::
-  
+
     $ git commit -m 'Post release updates'
 
 - If this is a **new branch** release (e.g. the first beta),
@@ -612,13 +612,13 @@ the main repo.
 - Commit and push to the main repo.::
 
     # Do a dry run first.
-    
+
     # For feature pre-releases prior to a **new branch** release,
     #   i.e. a feature alpha release:
     $ git push --dry-run --tags  git@github.com:python/cpython.git master
     # If it looks OK, take the plunge.  There's no going back!
     $ git push --tags  git@github.com:python/cpython.git master
-    
+
     # For a **new branch** release, i.e. first beta:
     $ git push --dry-run --tags  git@github.com:python/cpython.git X.Y
     $ git push --dry-run --tags  git@github.com:python/cpython.git master
@@ -635,10 +635,10 @@ the main repo.
   for the newly created branch (X.Y).  Look at the values for the previous
   release branch (X.Y-1) and use them as a template.
   https://github.com/python/cpython/settings/branches/
-  
+
   Also, add a ``needs backport to X.Y`` label to the Github repo.
   https://github.com/python/cpython/labels
-  
+
 - For all releases, if you made temporary changes to the permissions
   for the branch on GitHub, undo those temporary changes now.
   https://github.com/python/cpython/settings/branches/
@@ -660,7 +660,7 @@ at the moment, sorry.
 
 To do these steps, you must have the permission to edit the website.  If you
 don't have that, ask someone on pydotorg@python.org for the proper
-permissions.  (Or ask Ewa, who coordinated the effort for the new newbsite
+permissions.  (Or ask Ewa, who coordinated the effort for the new website
 with RevSys.)
 
 - Log in to https://www.python.org/admin .
@@ -809,7 +809,7 @@ with RevSys.)
 - If this is a **new branch** release, you will need to ensure various
   pieces of the development infrastructure are updated for the new branch.
   These include:
-  
+
   - Update the devguide to reflect the new branches and versions.
 
   - Ensure buildbots are defined for the new branch (contact zware).
@@ -831,7 +831,7 @@ with RevSys.)
     branches and that the release branch is properly protected (no direct
     pushes, etc).
 
-  - Verify that the on-line docs are building properly (this may take up to 
+  - Verify that the on-line docs are building properly (this may take up to
     24 hours for a complete build on the web site).
 
 

pep-0201.txt

@@ -281,7 +281,7 @@ References
 .. [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip
 
 
-Greg Wilson's questionaire on proposed syntax to some CS grad students
+Greg Wilson's questionnaire on proposed syntax to some CS grad students
 http://www.python.org/pipermail/python-dev/2000-July/013139.html
 
 

pep-0205.txt

@@ -125,7 +125,7 @@ underlying object, and proxy objects which masquerade as the
 original objects as much as possible.
 
 Reference objects are easy to work with when some additional layer
-of object managemenet is being added in Python; references can be
+of object management is being added in Python; references can be
 checked for liveness explicitly, without having to invoke
 operations on the referents and catching some special exception
 raised when an invalid weak reference is used.

pep-0207.txt

@@ -90,7 +90,7 @@ Proposed Resolutions
 1. Full backwards compatibility can be achieved as follows.  When
    an object defines ``tp_compare()`` but not ``tp_richcompare()``, and a
    rich comparison is requested, the outcome of ``tp_compare()`` is
-   used in the ovious way.  E.g. if "<" is requested, an exception if
+   used in the obvious way.  E.g. if "<" is requested, an exception if
    ``tp_compare()`` raises an exception, the outcome is 1 if
    ``tp_compare()`` is negative, and 0 if it is zero or positive.  Etc.
 

pep-0224.txt

@@ -160,7 +160,7 @@ The trailing slash would cause the Python compiler to concatenate
 the attribute value and the docstring.
 
 A modern syntax highlighting editor would easily make this
-accident visible, though, and by simply inserting emtpy lines
+accident visible, though, and by simply inserting empty lines
 between the attribute definition and the docstring you can avoid
 the possible concatenation completely, so the problem is
 negligible.

pep-0236.txt

@@ -73,7 +73,7 @@ name ``__future__``::
     feature: identifier
     name: identifier
 
-In addition, all future_statments must appear near the top of the module.  The
+In addition, all future_statements must appear near the top of the module.  The
 only lines that can appear before a future_statement are:
 
 + The module docstring (if any).
@@ -167,7 +167,7 @@ Standard Module __future__.py
 
 3. To document when incompatible changes were introduced, and when they will
    be-- or were --made mandatory.  This is a form of executable documentation,
-   and can be inspected programatically via importing ``__future__`` and
+   and can be inspected programmatically via importing ``__future__`` and
    examining its contents.
 
 Each statement in ``__future__.py`` is of the form::

pep-0245.txt

@@ -187,7 +187,7 @@ CountFishInterface and ColorFishInterface::
         def buySomeFish(quantity=1):
             "Buy some fish at the market"
 
-The FishMarketInteface extends upon the CountFishInterface and
+The FishMarketInterface extends upon the CountFishInterface and
 ColorfishInterface.
 
 
@@ -293,7 +293,7 @@ or a tuple of interface assertions.  For example::
 
     FooInterface
 
-    FooInterface, (BarInteface, BobInterface)
+    FooInterface, (BarInterface, BobInterface)
 
     FooInterface, (BarInterface, (BobInterface, MyClass.__implements__))
 

pep-0266.txt

@@ -54,7 +54,7 @@ In an attempt to gauge the effect of this proposal, I modified the Pystone
 benchmark program included in the Python distribution to cache global
 functions.  Its main function, ``Proc0``, makes calls to ten different
 functions inside its ``for`` loop.  In addition, ``Func2`` calls ``Func1``
-repeatedly inside a loop.  If local copies of these 11 global idenfiers are
+repeatedly inside a loop.  If local copies of these 11 global identifiers are
 made before the functions' loops are entered, performance on this particular
 benchmark improves by about two percent (from 5561 pystones to 5685 on my
 laptop).  It gives some indication that performance would be improved by

pep-0275.txt

@@ -120,7 +120,7 @@ well-known immutable types (strings, unicode, numbers) and
 use the hash table for finding the right opcode snippet. If
 this condition is not met, the interpreter should revert to
 the standard if-elif-else processing by simply skipping the
-SWITCH opcode and procedding with the usual if-elif-else byte
+SWITCH opcode and proceeding with the usual if-elif-else byte
 code stream.
 
 
@@ -129,7 +129,7 @@ Issues:
 The new optimization should not change the current Python
 semantics (by reducing the number of ``__cmp__`` calls and adding
 ``__hash__`` calls in if-elif-else constructs which are affected
-by the optimiztation). To assure this, switching can only
+by the optimization). To assure this, switching can only
 safely be implemented either if a "from __future__" style
 flag is used, or the switching variable is one of the builtin
 immutable types: int, float, string, unicode, etc. (not

pep-0280.txt

@@ -312,7 +312,7 @@ Additional Ideas
               # we're checking the builtin dict for that *now*, this
               # still works if the builtin first came into existence
               # after we were constructed.  Note too that del on
-              # namespace dicts is rare, so the expensse of this check
+              # namespace dicts is rare, so the expense of this check
               # shouldn't matter.
               if key in self.basedict:
                   c.objptr = self.basedict[key]

pep-0304.txt

@@ -91,7 +91,7 @@ During import, this extension works as follows:
 - If no byte-compiled file is found, an attempt to read a
   byte-compiled file from the augmented directory is made.
 
-- If bytecode generation is required, the generated bytecode is wrtten
+- If bytecode generation is required, the generated bytecode is written
   to the augmented directory if possible.
 
 Note that this PEP is explicitly *not* about providing

pep-0319.txt

@@ -407,9 +407,9 @@ is equivalent to the proposed::
     synchronize the_lock:
         change_shared_data()
 
-PEP 310 must synchronize on an exsiting lock, while this PEP
+PEP 310 must synchronize on an existing lock, while this PEP
 proposes that unqualified 'synchronize' statements synchronize on
-a global, internal, transparent lock in addition to qualifiled
+a global, internal, transparent lock in addition to qualified
 'synchronize' statements.  The 'with' statement also requires lock
 initialization, while the 'synchronize' statement can synchronize
 on any target object **including** locks.

pep-0327.txt

@@ -418,7 +418,7 @@ incremented by 1 (round toward positive infinity)::
 ``round-floor``: If all of the discarded digits are zero or if the
 sign is positive the result is unchanged; otherwise, the absolute
 value of the result is incremented by 1 (round toward negative
-infinty)::
+infinity)::
 
      1.123 -->  1.12
      1.128 -->  1.12

pep-0333.txt

@@ -872,7 +872,7 @@ portion of the response that precedes it.
 
 In these cases, applications will usually return an iterator (often
 a generator-iterator) that produces the output in a block-by-block
-fashion.  These blocks may be broken to coincide with mulitpart
+fashion.  These blocks may be broken to coincide with multipart
 boundaries (for "server push"), or just before time-consuming
 tasks (such as reading another block of an on-disk file).
 

pep-0336.txt

@@ -22,7 +22,7 @@ BDFL Pronouncement
 
 This PEP is rejected.  It is considered a feature that ``None`` raises
 an error when called.  The proposal falls short in tests for
-obviousness, clarity, explictness, and necessity.  The provided Switch
+obviousness, clarity, explicitness, and necessity.  The provided Switch
 example is nice but easily handled by a simple lambda definition.
 See python-dev discussion on 17 June 2005 [2]_.
 

pep-0345.txt

@@ -239,7 +239,7 @@ License (optional)
 Text indicating the license covering the distribution where the license
 is not a selection from the "License" Trove classifiers. See
 "Classifier" below.  This field may also be used to specify a
-particular version of a licencse which is named via the ``Classifier``
+particular version of a license which is named via the ``Classifier``
 field, or to indicate a variation or exception to such a license.
 
 Examples::

pep-0353.txt

@@ -214,7 +214,7 @@ Py_ssize_t is just a typedef for int.
 On a 64-bit system, the compiler will warn in many
 places. If these warnings are ignored, the code will
 continue to work as long as the container sizes don't
-exceeed 2**31, i.e. it will work nearly as good as
+exceed 2**31, i.e. it will work nearly as good as
 it does currently. There are two exceptions to this
 statement: if the extension module implements the
 sequence protocol, it must be updated, or the calling

pep-0359.txt

@@ -472,7 +472,7 @@ equivalent nesting with a much more explicit syntax::
                 h1.tail = 'after second h1'
 
 And if the repetition of the element names here is too much of a DRY
-violoation, it is also possible to eliminate all as-clauses except for
+violation, it is also possible to eliminate all as-clauses except for
 the first by adding a few methods to Element. [10]_
 
 So are there real use-cases for executing the block in a dict of a

pep-0369.txt

@@ -133,7 +133,7 @@ The import hook system guarantees certain invariants. XXX
 Sample Python implementation
 ----------------------------
 
-A Python implemenation may look like::
+A Python implementation may look like::
 
       def notify(name):
           try:

pep-0370.txt

@@ -163,7 +163,7 @@ directories are created on demand.
 
 ``distutils.command.build_ext`` (setup.py build_ext) gets a new argument
 ``--user`` which adds the include/ and lib/ directories in the user base
-dirctory to the search paths for header files and libraries. It also
+directory to the search paths for header files and libraries. It also
 adds the lib/ directory to rpath.
 
 The ``site`` module gets two arguments ``--user-base`` and ``--user-site``

pep-0378.txt

@@ -229,7 +229,7 @@ Commentary
   ten-thousands.  Eric Smith pointed-out that these are already
   handled by the "n" specifier in the locale module (albeit only
   for integers).  This PEP does not attempt to support all of those
-  possibilities.  It focues on a single, relatively common grouping
+  possibilities.  It focuses on a single, relatively common grouping
   convention that offers a quick way to improve readability in many
   (though not all) contexts.
 

pep-0381.txt

@@ -87,7 +87,7 @@ PyPI provides statistics on downloads at `/stats`. This page is
 calculated daily by PyPI, by reading all mirrors' local stats and
 summing them.
 
-The stats are presented in daily or montly files, under `/stats/days`
+The stats are presented in daily or monthly files, under `/stats/days`
 and `/stats/months`. Each file is a `bzip2` file with these formats:
 
 - YYYY-MM-DD.bz2 for daily files
@@ -290,7 +290,7 @@ Clients that are browsing PyPI should be able to use a fail-over
 mechanism when PyPI or the used mirror is not responding.
 
 It is up to the client to decide wich mirror should be used, maybe by
-looking at its geographical location and its responsivness.
+looking at its geographical location and its responsiveness.
 
 This PEP does not describe how this fail-over mechanism should work,
 but it is strongly encouraged that the clients try to use the nearest

pep-0382.txt

@@ -175,15 +175,15 @@ extensions related to Python should start with ``.py``. Therefore, the
 marker file was renamed to be ``.pyp``.
 
 Dinu Gherman then observed that using a marker file is not necessary,
-and that a directoy extension could well serve as a such as a
+and that a directory extension could well serve as a such as a
 marker. This is what this PEP currently proposes.
 
 Phillip Eby designed PEP 402 as an alternative approach to this PEP,
 after comparing Python's package syntax with that found in other
 languages. PEP 402 proposes not to use a marker file at all. At the
 discussion at PyCon DE 2011, people remarked that having an explicit
 declaration of a directory as contributing to a package is a desirable
-property, rather than an obstactle. In particular, Jython developers
+property, rather than an obstacle. In particular, Jython developers
 noticed that Jython could easily mistake a directory that is a Java
 package as being a Python package, if there is no need to declare
 Python packages.

pep-0406.txt

@@ -256,7 +256,7 @@ References
 .. [3] Importlib documentation, Cannon
   (http://docs.python.org/dev/library/importlib)
 
-.. [4] Reference implentation
+.. [4] Reference implementation
   (https://bitbucket.org/jergosh/gsoc_import_engine/src/default/Lib/importlib/engine.py)
 
 

pep-0416.txt

@@ -185,14 +185,14 @@ Blacklist approach: inherit from dict and override write methods to raise an
 exception. It is not truly read-only: it is still possible to call dict methods
 on such "frozen dictionary" to modify it.
 
-* brownie: `brownie.datastructures.ImmuatableDict
+* brownie: `brownie.datastructures.ImmutableDict
   <https://github.com/DasIch/brownie/blob/HEAD/brownie/datastructures/mappings.py>`_.
   It is hashable if keys and values are hashable. werkzeug project has the
   same code: `werkzeug.datastructures.ImmutableDict
   <https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/datastructures.py>`_.
   ImmutableDict is used for global constant (configuration options). The Flask
   project uses ImmutableDict of werkzeug for its default configuration.
-* SQLAchemy project: `sqlachemy.util.immutabledict
+* SQLAlchemy project: `sqlalchemy.util.immutabledict
   <http://hg.sqlalchemy.org/sqlalchemy/file/tip/lib/sqlalchemy/util/_collections.py>`_.
   It is not hashable and has an extra method: union(). immutabledict is used
   for the default value of parameter of some functions expecting a mapping.

pep-0418.txt

@@ -81,7 +81,7 @@ Limitations:
   documentation of new functions. The behaviour depends on the
   operating system: see the `Monotonic Clocks`_ section below. Some
   recent operating systems provide two clocks, one including time
-  elapsed during system suspsend, one not including this time. Most
+  elapsed during system suspend, one not including this time. Most
   operating systems only provide one kind of clock.
 * time.monotonic() and time.perf_counter() may or may not be adjusted.
   For example, ``CLOCK_MONOTONIC`` is slewed on Linux, whereas

pep-0423.txt

@@ -149,7 +149,7 @@ Ownership could be:
 
   * `zest.releaser`_ is owned and maintained by Zest Software.
   * `Django`_ is owned and maintained by the Django Software
-    Fundation.
+    Foundation.
 
 * a group or community.
   Example: `sphinx`_ is maintained by developers of the Sphinx

pep-0425.txt

@@ -262,7 +262,7 @@ Why didn't you mention my favorite Python implementation?
 Why is the ABI tag (the second tag) sometimes "none" in the reference implementation?
     Since Python 2 does not have an easy way to get to the SOABI
     (the concept comes from newer versions of Python 3) the reference
-    implentation at the time of writing guesses "none".  Ideally it
+    implementation at the time of writing guesses "none".  Ideally it
     would detect "py27(d|m|u)" analogous to newer versions of Python,
     but in the meantime "none" is a good enough way to say "don't know".
 

pep-0426.txt

@@ -1029,7 +1029,7 @@ If the standard ``alldev`` extra has no explicitly declared entries, then
 integration tools SHOULD implicitly define it as a dependency on the standard
 ``test``, ``build``, ``doc``, and ``dev`` extras.
 
-The full set of dependency requirements is then based on the uncondtional
+The full set of dependency requirements is then based on the unconditional
 dependencies, along with those of any requested extras.
 
 Dependency examples (showing just the ``requires`` subfield)::