Typos found by codespell (#2073)

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

pep-0002.txt

@@ -67,7 +67,7 @@ Maintainer(s)
 All contributions to the standard library need one or more
 maintainers.  This can be an individual, but it is frequently a group
 of people such as the XML- SIG.  Groups may subdivide maintenance
-tasks among themselves.  One ore more maintainers shall be the *head
+tasks among themselves.  One or more maintainers shall be the *head
 maintainer* (usually this is also the main developer).  Head
 maintainers are convenient people the integrators can address if they
 want to resolve specific issues, such as the ones detailed later in

pep-0042.txt

@@ -106,7 +106,7 @@ Standard Library
   handler, it returns "".  It would be better to make it raise an
   exception (corresponding to EINTR) or to restart.  But these
   changes would have to applied to all places that can do blocking
-  interruptable I/O.  So it's a big project.
+  interruptible I/O.  So it's a big project.
 
   https://bugs.python.org/issue210599
 

pep-0101.txt

@@ -534,7 +534,7 @@ the main repo.
   you will now need to manual remove each blurb entry from
   the ``Misc/NEWS.d/next`` directory that was cherry-picked
   into the release you are working on since that blurb entry
-  is now captured in the merged x.y.z.rst fils for the new
+  is now captured in the merged x.y.z.rst file for the new
   release.  Otherwise, the blurb entry will appear twice in
   the `changelog.html` file, once under `Python next` and again
   under `x.y.z`.

pep-0214.txt

@@ -193,7 +193,7 @@ symbol.
   necessary!  Of course you want the file to be an arbitrary
   expression, not just a single word.  (You definitely want to be
   able to write ``print >>sys.stderr``.)  Without the expression the
-  parser would't be able to distinguish where that expression ends
+  parser wouldn't be able to distinguish where that expression ends
   and where the next one begins, e.g.
 
   ::

pep-0252.txt

@@ -623,7 +623,7 @@ this situation substantially.
 
 - Modification for dynamic types: step 1 and 3 look in the
   dictionary of the type and all its base classes (in MRO
-  sequence, or couse).
+  sequence, or course).
 
 
 Discussion

pep-0287.txt

@@ -271,7 +271,7 @@ SText idea, addressing all of the problems listed above.
 Specification
 =============
 
-The specification and user documentaton for reStructuredText is
+The specification and user documentation for reStructuredText is
 quite extensive.  Rather than repeating or summarizing it all
 here, links to the originals are provided.
 

pep-0340.txt

@@ -270,7 +270,7 @@ Alternatives Considered and Rejected
   an entirely different API than the for-loop, to differentiate
   between the two.  A generator would have to be wrapped in a
   decorator to make it support the block API.  IMO this adds more
-  complexity with very little benefit; and we can't relly deny
+  complexity with very little benefit; and we can't really deny
   that the block-statement is conceptually a loop -- it supports
   break and continue, after all.
 

pep-0367.txt

@@ -481,7 +481,7 @@ The proposal adds a dynamic attribute lookup to the super type, which will
 automatically determine the proper class and instance parameters. Each super
 attribute lookup identifies these parameters and performs the super lookup on
 the instance, as the current super implementation does with the explicit
-invokation of a super instance upon a class and instance.
+invocation of a super instance upon a class and instance.
 
 This proposal relies on sys._getframe(), which is not appropriate for anything
 except a prototype implementation.

pep-0372.txt

@@ -249,7 +249,7 @@ What are the trade-offs of the possible underlying data structures?
      the code a little bit more complex.  All of the basic operations are O(1)
      but the constant factor is increased for __setitem__() and __delitem__()
      meaning that every use case will have to pay for this speedup (since all
-     buildup go through __setitem__). Also, the first traveral incurs a
+     buildup go through __setitem__). Also, the first traversal incurs a
      one-time ``O(n log n)`` sorting cost.  The storage costs are double that
      for the sorted-list-of-keys approach.
 

pep-0374.txt

@@ -1443,7 +1443,7 @@ admitted that svn does not serve the needs of non-committers as well
 as a DVCS does. Because svn only provides its features such as version
 control, branching, etc. to people with commit privileges on the
 repository it can be a hindrance for people who lack commit
-privileges. But DVCSs have no such limitiation as anyone can create a
+privileges. But DVCSs have no such limitation as anyone can create a
 local branch of Python and perform their own local commits without the
 burden that comes with cloning the entire svn repository. Allowing
 anyone to have the same workflow as the core developers was the key

pep-0389.txt

@@ -42,7 +42,7 @@ a valuable addition to the Python libraries.
 
 Why aren't getopt and optparse enough?
 ======================================
-One argument against adding argparse is that thare are "already two
+One argument against adding argparse is that there are "already two
 different option parsing modules in the standard library" [9]_. The
 following is a list of features provided by argparse but not present
 in getopt or optparse:

pep-0400.txt

@@ -192,7 +192,7 @@ file-like objects (same API).
 codecs.open() was the only way to open a text file in Unicode mode
 until Python 2.6. Many Python 2 programs uses this function. Removing
 codecs.open() implies more work to port programs from Python 2 to
-Python 3, especially projets using the same code base for the two
+Python 3, especially projects using the same code base for the two
 Python versions (without using 2to3 program).
 
 codecs.open() is kept for backward compatibility with Python 2.
@@ -201,7 +201,7 @@ codecs.open() is kept for backward compatibility with Python 2.
 Deprecate StreamReader and StreamWriter
 '''''''''''''''''''''''''''''''''''''''
 
-Instanciating StreamReader or StreamWriter must emit a DeprecationWarning in
+Instantiating StreamReader or StreamWriter must emit a DeprecationWarning in
 Python 3.3. Defining a subclass doesn't emit a DeprecationWarning.
 
 codecs.open() will be changed to reuse the builtin open() function

pep-0423.txt

@@ -561,7 +561,7 @@ Actions:
 
   * if you use the `default convention
     <#use-standard-pattern-for-community-contributions>`_, then this
-    document should be enough. Don't reapeat it. You may reference
+    document should be enough. Don't repeat it. You may reference
     it.
 
   * else, tell users about custom conventions in project's

pep-0425.txt

@@ -114,7 +114,7 @@ the CPython 3.3 ABI with debugging.
 The CPython stable ABI is `abi3` as in the shared library suffix.
 
 Implementations with a very unstable ABI may use the first 6 bytes (as
-8 base64-encoded characters) of the SHA-256 hash of ther source code
+8 base64-encoded characters) of the SHA-256 hash of their source code
 revision and compiler flags, etc, but will probably not have a great need
 to distribute binary distributions. Each implementation's community may
 decide how to best use the ABI tag.
@@ -226,7 +226,7 @@ What tag do I use if my distribution uses a feature exclusive to the newest vers
 Why isn't there a `.` in the Python version number?
     CPython has lasted 20+ years without a 3-digit major release. This
     should continue for some time.  Other implementations may use _ as
-    a delimeter, since both - and . delimit the surrounding filename.
+    a delimiter, since both - and . delimit the surrounding filename.
 
 Why normalise hyphens and other non-alphanumeric characters to underscores?
     To avoid conflicting with the "." and "-" characters that separate

pep-0439.txt

@@ -17,7 +17,7 @@ Resolution: https://mail.python.org/pipermail/distutils-sig/2013-August/022527.h
 Abstract
 ========
 
-This PEP proposes the inclusion of a pip boostrap executable in the
+This PEP proposes the inclusion of a pip bootstrap executable in the
 Python installation to simplify the use of 3rd-party modules by Python
 users.
 
@@ -91,7 +91,7 @@ and virtualenv.  Once installed, the pip command proceeds as normal. Once the
 bootstrap process is complete the "pip3" command is no longer the bootstrap
 but rather the full pip command.
 
-A boostrap is used in the place of a the full pip code so that we don't have
+A bootstrap is used in the place of a the full pip code so that we don't have
 to bundle pip and also pip is upgradeable outside of the regular Python
 upgrade timeframe and processes.
 
@@ -110,7 +110,7 @@ The bootstrap process will proceed as follows:
    called "pip3".
 2. The user will invoke a pip command, typically "pip3 install
    <package>", for example "pip3 install Django".
-3. The boostrap script will attempt to import the pip implementation.
+3. The bootstrap script will attempt to import the pip implementation.
    If this succeeds, the pip command is processed normally. Stop.
 4. On failing to import the pip implementation the bootstrap notifies
    the user that it needs to "install pip". It will ask the user whether it
@@ -140,11 +140,11 @@ CA certificate check performed. This facility will be present in Python 3.4+
 using Operating System certificates (see PEP XXXX).
 
 Beyond those arguments controlling index location and download
-options, the "pip3" boostrap command may support further standard pip
+options, the "pip3" bootstrap command may support further standard pip
 options for verbosity, quietness and logging.
 
 The "pip3" command will support two new command-line options that are used
-in the boostrapping, and otherwise ignored. They control where the pip
+in the bootstrapping, and otherwise ignored. They control where the pip
 implementation is installed:
 
 ``--bootstrap``

pep-0442.txt

@@ -34,7 +34,7 @@ Reference
 
 Weak reference
     A directional link from an object to another, which doesn't keep
-    alive its target.  This PEP focusses on non-weak references.
+    alive its target.  This PEP focuses on non-weak references.
 
 Reference cycle
     A cyclic subgraph of directional links between objects, which keeps

pep-0447.txt

@@ -40,7 +40,7 @@ to::
 
          return NotFound
 
-The default implemention of ``__getdescriptor__`` looks in the class
+The default implementation of ``__getdescriptor__`` looks in the class
 dictionary::
 
    class type:
@@ -669,7 +669,7 @@ Discussion threads
 * The initial version of the PEP was send with
   Message-ID `<75030FAC-6918-4E94-95DA-67A88D53E6F5@mac.com>`_
 
-* Further discusion starting at a message with
+* Further discussion starting at a message with
   Message-ID `<5BB87CC4-F31B-4213-AAAC-0C0CE738460C@mac.com>`_
 
 * And more discussion starting at message with

pep-0452.txt

@@ -236,7 +236,7 @@ Changes
 * 2001-09-20: Removed ``reset()`` method completely.
 * 2001-09-28: Set ``digest_size`` to ``None`` for variable-size hashes.
 * 2013-08-15: Added ``block_size`` and ``name`` attributes; clarified that
-  'string' actually referes to bytes-like objects.
+  'string' actually refers to bytes-like objects.
 
 
 Acknowledgements

pep-0454.txt

@@ -78,7 +78,7 @@ implemented in the PySizer project in 2005. PySizer was implemented
 differently: the traceback was stored in frame objects and some Python
 types were linked the trace with the name of object type. PySizer patch
 on CPython adds an overhead on performances and memory footprint, even if
-the PySizer was not used. tracemalloc attachs a traceback to the
+the PySizer was not used. tracemalloc attaches a traceback to the
 underlying layer, to memory blocks, and has no overhead when the module
 is not tracing memory allocations.
 
@@ -313,7 +313,7 @@ Snapshot
 
     All inclusive filters are applied at once, a trace is ignored if no
     inclusive filters match it. A trace is ignored if at least one
-    exclusive filter matchs it.
+    exclusive filter matches it.
 
 
 ``load(filename)`` classmethod:
@@ -526,7 +526,7 @@ Prior Work
   <https://pypi.python.org/pypi/meliae>`_:
   Python Memory Usage Analyzer developed by John A Meinel since 2009
 * `gdb-heap <https://fedorahosted.org/gdb-heap/>`_: gdb script written in
-  Python by Dave Malcom (2010-2011) to analyze the usage of the heap memory
+  Python by Dave Malcolm (2010-2011) to analyze the usage of the heap memory
 * `memory_profiler <https://pypi.python.org/pypi/memory_profiler>`_:
   written by Fabian Pedregosa (2011-2013)
 * `caulk <https://github.com/smartfile/caulk/>`_: written by Ben Timby in 2012

pep-0457.txt

@@ -45,7 +45,7 @@ variadic ``*args`` parameter.  However, there is no Python
 syntax to specify accepting a specific number of
 positional-only parameters.  Put another way, there are
 many builtin functions whose signatures are simply not
-expressable with Python syntax.
+expressible with Python syntax.
 
 This PEP proposes a notation for such signatures that could form the
 basis of a backwards-compatible syntax that should permit implementing

pep-0467.txt

@@ -116,7 +116,7 @@ order functions like ``map``.
 
 These new methods intentionally do NOT offer the same level of general integer
 support as the existing ``int.to_bytes`` conversion method, which allows
-arbitrarily large integers to be converted to arbitarily long bytes objects. The
+arbitrarily large integers to be converted to arbitrarily long bytes objects. The
 restriction to only accept positive integers that fit in a single byte means
 that no byte order information is needed, and there is no need to handle
 negative numbers. The documentation of the new methods will refer readers to

pep-0475.txt

@@ -399,7 +399,7 @@ Closed issues:
   <http://bugs.python.org/issue1049450>`_
 * `subprocess: Popen.communicate() doesn't handle EINTR in some cases
   <http://bugs.python.org/issue12493>`_
-* `multiprocessing.util._eintr_retry doen't recalculate timeouts
+* `multiprocessing.util._eintr_retry doesn't recalculate timeouts
   <http://bugs.python.org/issue12338>`_
 * `file readline, readlines & readall methods can lose data on EINTR
   <http://bugs.python.org/issue12268>`_

pep-0485.txt

@@ -115,7 +115,7 @@ However, users may want to compare other numeric types similarly. In
 theory, it should work for any type that supports ``abs()``,
 multiplication, comparisons, and subtraction. However, the implementation
 in the math module is written in C, and thus can not (easily) use python's
-duck typing. Rather, the values passed into the funciton will be converted
+duck typing. Rather, the values passed into the function will be converted
 to the float type before the calculation is performed. Passing in types
 (or values) that cannot be converted to floats will raise an appropriate
 Exception (TypeError, ValueError, or OverflowError).

pep-0490.txt

@@ -168,7 +168,7 @@ exceptions.
 
 The reference cycle can now be fixed with the new
 ``traceback.TracebackException`` object introduced in Python 3.5. It
-stores informations required to format a full textual traceback without
+stores information required to format a full textual traceback without
 storing local variables.
 
 The ``asyncio`` is impacted by the reference cycle issue. This module

pep-0509.txt

@@ -310,7 +310,7 @@ Expose the version at Python level as a read-only __version__ property
 
 The first version of the PEP proposed to expose the dictionary version
 as a read-only ``__version__`` property at Python level, and also to add
-the property to ``collections.UserDict`` (since this type must mimick
+the property to ``collections.UserDict`` (since this type must mimic
 the ``dict`` API).
 
 There are multiple issues:

pep-0510.txt

@@ -250,7 +250,7 @@ function::
                 # use the specialized code
                 return specialized_code
             elif check == 1:
-                # a guard failed temporarely:
+                # a guard failed temporarily:
                 # try the next specialized code
                 index += 1
             else:
@@ -315,7 +315,7 @@ The ``init()`` function initializes a guard:
 The ``check()`` function checks a guard:
 
 * Return ``0`` on success
-* Return ``1`` if the guard failed temporarely
+* Return ``1`` if the guard failed temporarily
 * Return ``2`` if the guard will always fail: the specialized code must
   be removed
 * Raise an exception and return ``-1`` on error

pep-0511.txt

@@ -514,7 +514,7 @@ Output::
 AST transformer
 ---------------
 
-Similary to the bytecode transformer example, the AST transformer also
+Similarly to the bytecode transformer example, the AST transformer also
 replaces all strings with ``"Ni! Ni! Ni!"``::
 
     import ast

pep-0519.txt

@@ -518,7 +518,7 @@ References
 .. [#python-dev-archive] The python-dev mailing list archive
    (https://mail.python.org/pipermail/python-dev/)
 
-.. [#libc-open] ``open()`` documention for the C standard library
+.. [#libc-open] ``open()`` documentation for the C standard library
    (http://www.gnu.org/software/libc/manual/html_node/Opening-and-Closing-Files.html)
 
 .. [#pathlib] The ``pathlib`` module

pep-0523.txt

@@ -245,7 +245,7 @@ It should be mentioned that the Pyston team was consulted on an
 earlier version of this PEP that was more JIT-specific and they were
 not interested in utilizing the changes proposed because they want
 control over memory layout they had no interest in directly supporting
-CPython itself. An informal discusion with a developer on the PyPy
+CPython itself. An informal discussion with a developer on the PyPy
 team led to a similar comment.
 
 Numba [#numba]_, on the other hand, suggested that they would be

pep-0525.txt

@@ -416,7 +416,7 @@ The data flow is defined as follows:
    unwrapped value as an argument.
 
 2. When ``PyAsyncGenASend.throw(*exc)`` is called for the first time,
-   ``*exc`` is throwed into the parent ``agen`` object.
+   ``*exc`` is thrown into the parent ``agen`` object.
 
    Subsequent iterations over the ``PyAsyncGenASend`` objects, push
    ``None`` to ``agen``.

pep-0531.txt

@@ -269,7 +269,7 @@ appropriate operation (e.g. ``math.isnan``, ``cmath.isnan``,
 
 Similarly, it seems reasonable to declare that the other placeholder builtin
 singletons, ``Ellipsis`` and ``NotImplemented``, also qualify as objects that
-represent the absence of data moreso than they represent data.
+represent the absence of data more so than they represent data.
 
 
 Proposed symbolic notation

pep-0554.rst

@@ -844,7 +844,7 @@ API for sharing data
 Subinterpreters are less useful without a mechanism for sharing data
 between them.  Sharing actual Python objects between interpreters,
 however, has enough potential problems that we are avoiding support
-for that here.  Instead, only mimimum set of types will be supported.
+for that here.  Instead, only minimum set of types will be supported.
 Initially this will include ``None``, ``bytes``, ``str``, ``int``,
 and channels.  Further types may be supported later.
 
@@ -956,7 +956,7 @@ The module also provides the following channel-related classes::
 Channel Lifespan
 ----------------
 
-A channel is automatically closed and destoyed once there are no more
+A channel is automatically closed and destroyed once there are no more
 Python objects (e.g. ``RecvChannel`` and ``SendChannel``) referring
 to it.  So it is effectively triggered via garbage-collection of those
 objects..
@@ -1258,7 +1258,7 @@ this can wait.
 Pipes and Queues
 ----------------
 
-With the proposed object passing machanism of "channels", other similar
+With the proposed object passing mechanism of "channels", other similar
 basic types aren't required to achieve the minimal useful functionality
 of subinterpreters.  Such types include pipes (like unbuffered channels,
 but one-to-one) and queues (like channels, but more generic).  See below

pep-0575.rst

@@ -551,7 +551,7 @@ Some of these are existing (possibly changed) functions, some are new:
   if the type of ``op`` is ``function``.
 
 - ``PyObject *PyFunction_NewPython(PyTypeObject *cls, PyObject *code, PyObject *globals, PyObject *name, PyObject *qualname)``:
-  create a new instance of ``cls`` (which must be a sublass of ``function``)
+  create a new instance of ``cls`` (which must be a subclass of ``function``)
   from the given data.
 
 - ``PyObject *PyFunction_New(PyObject *code, PyObject *globals)``:
@@ -561,7 +561,7 @@ Some of these are existing (possibly changed) functions, some are new:
   create a new instance of ``function``.
 
 - ``PyObject *PyFunction_Copy(PyTypeObject *cls, PyObject *func)``:
-  create a new instance of ``cls`` (which must be a sublass of ``function``)
+  create a new instance of ``cls`` (which must be a subclass of ``function``)
   by copying a given ``function``.
 
 Changes to the types module

pep-0587.rst

@@ -1332,7 +1332,7 @@ Issues that will be fixed by this PEP, directly or indirectly:
   callback system for Py_FatalError"
 * `bpo-11320 <https://bugs.python.org/issue11320>`_:
   "Usage of API method Py_SetPath causes errors in Py_Initialize()
-  (Posix ony)"
+  (Posix only)"
 * `bpo-13533 <https://bugs.python.org/issue13533>`_: "Would like
   Py_Initialize to play friendly with host app"
 * `bpo-14956 <https://bugs.python.org/issue14956>`_: "custom PYTHONPATH

pep-0605.rst

@@ -1302,7 +1302,7 @@ In some cases, both usage models may exist within the same organisation for
 different purposes, such as:
 
 * using a stable Python environment for mission critical systems, but allowing
-  data scientists to use the latest available version for ad hoc data anaylsis
+  data scientists to use the latest available version for ad hoc data analysis
 * a hardware manufacturer deploying a stable Python version as part of their
   production firmware, but using the latest available version in the development
   and execution of their automated integration tests

pep-0610.rst

@@ -270,7 +270,7 @@ present as a dictionary with the following key:
 - ``editable`` (type: ``boolean``): ``true`` if the distribution was installed
   in editable mode, ``false`` otherwise. If absent, default to ``false``.
 
-When ``url`` refers to a local directory, it MUST have the ``file`` sheme
+When ``url`` refers to a local directory, it MUST have the ``file`` scheme
 and be compliant with `RFC 8089`_. In particular, the path component must
 be absolute. Symbolic links SHOULD be preserved when making relative
 paths absolute.

pep-0612.rst

@@ -435,7 +435,7 @@ afforded to us by this set up:
   ``Tuple[P.args, ...]`` as would be with a normal annotation
   (and likewise with the ``**kwargs``\ )
 
-  * This special case is necessary to encapsulate the heterogenous contents
+  * This special case is necessary to encapsulate the heterogeneous contents
     of the ``args``/``kwargs`` of a given call, which cannot be expressed
     by an indefinite tuple/dictionary type.
 

pep-0633.rst

@@ -136,7 +136,7 @@ The keys of the requirement table are as follows (all are optional):
   of the amendment.
 
 - ``revision`` (string): the identifier for a specific revision of the
-  specified VCS repository to check-out before installtion. Users MUST only
+  specified VCS repository to check-out before installation. Users MUST only
   provide this when one of ``git``, ``hg``, ``bzr``, ``svn``, or another VCS
   key is used to identify the distribution to install. Revision identifiers are
   suggested in :pep:`610`.

pep-0634.rst

@@ -402,7 +402,7 @@ subpatterns succeed in matching their corresponding item, the sequence
 pattern succeeds.
 
 A variable-length sequence pattern first matches the leading non-star
-subpatterns to the curresponding items of the subject sequence, as for
+subpatterns to the corresponding items of the subject sequence, as for
 a fixed-length sequence.  If this succeeds, the star subpattern
 matches a list formed of the remaining subject items, with items
 removed from the end corresponding to the non-star subpatterns

pep-0637.rst

@@ -962,7 +962,7 @@ expecting a call like::
 
     type(obj).__setitem__(obj, SENTINEL, 0, **{"value": 1})
 
-will instead accidentally be catched by the named ``value``, producing a
+will instead accidentally be caught by the named ``value``, producing a
 ``duplicate value error``. The user should not be worried about the actual
 local names of those two arguments if they are, for all practical purposes,
 positional only. Unfortunately, using positional-only values will ensure this

pep-0642.rst

@@ -58,7 +58,7 @@ types as follows:
 * group patterns: ``(PTRN)``
 * value constraint patterns:
     * equality constraints: ``== EXPR``
-    * identity contraints: ``is EXPR``
+    * identity constraints: ``is EXPR``
 * structural constraint patterns:
     * sequence constraint patterns: ``[PTRN, as NAME, PTRN as NAME]``
     * mapping constraint patterns: ``{EXPR: PTRN, EXPR as NAME}``
@@ -239,7 +239,7 @@ restricted to top level patterns and to group patterns (which are patterns
 surrounded by parentheses).
 
 Closed patterns are patterns which either consist of a single token
-(i.e. ``__``), or else have a closing delimeter as a required part of their
+(i.e. ``__``), or else have a closing delimiter as a required part of their
 syntax (e.g. ``[as x, as y]``, ``object{.x as x, .y as y}``).
 
 As in PEP 634, the ``match`` and ``case`` keywords are soft keywords, i.e. they
@@ -1228,7 +1228,7 @@ Changes to sequence patterns
 This PEP makes one notable change to sequence patterns relative to PEP 634:
 
 * only the square bracket form of sequence pattern is supported. Neither open
-  (no delimeters) nor tuple style (parentheses as delimiters) sequence patterns
+  (no delimiters) nor tuple style (parentheses as delimiters) sequence patterns
   are supported.
 
 Relative to PEP 634, sequence patterns are also significantly affected by the
@@ -1243,7 +1243,7 @@ flexibility that had been included in the original syntax proposal purely for
 consistency with iterable unpacking.
 
 Allowing open and tuple style sequence patterns didn't increase expressivity,
-only ambiguity of intent (especially relative to group paterns), and encouraged
+only ambiguity of intent (especially relative to group patterns), and encouraged
 readers down the path of viewing pattern matching syntax as intrinsically linked
 to assignment target syntax (which the PEP 634 authors have stated multiple
 times is not a desirable path to have readers take, and a view the author of
@@ -1540,7 +1540,7 @@ membership check in Python::
         case == 0 | == 1 | == 2 | == 3:
             ...
 
-Allowing inferred equality contraints under this PEP would only make it look
+Allowing inferred equality constraints under this PEP would only make it look
 like the PEP 634 example, it still wouldn't look like the equivalent ``if``
 statement header (``if value in {0, 1, 2, 3}:``).
 

pep-0646.rst

@@ -1142,7 +1142,7 @@ A question we are often asked about this PEP is: why not just use named tensors?
 The answer is that we consider the named tensors approach insufficient, for two main reasons:
 
 * **Static checking** of shape correctness is not possible. As mentioned in `Motivation`_,
-  this is a highly desireable feature in machine learning code where iteration times
+  this is a highly desirable feature in machine learning code where iteration times
   are slow by default.
 * **Interface documentation** is still not possible with this approach. If a function should
   *only* be willing to take array arguments that have image-like shapes, this cannot be stipulated

pep-0651.rst

@@ -148,7 +148,7 @@ PyLeaveRecursiveCall()
 Backwards Compatibility
 =======================
 
-This feature is fully backwards compatibile at the Python level.
+This feature is fully backwards compatible at the Python level.
 Some low-level tools, such as machine-code debuggers, will need to be modified.
 For example, the gdb scripts for Python will need to be aware that there may be more than one Python frame
 per C frame.

pep-0652.rst

@@ -71,7 +71,7 @@ but has major issues: for example, the set exported symbols has
 platform-specific variations.
 Also, the cost of updating an explicit manifest is small compared
 to the overall work that should go into changing API that will need to
-be suppported forever (or until Python 3 reaches end of life, if that
+be supported forever (or until Python 3 reaches end of life, if that
 comes sooner).
 
 This PEP proposes automatically generating things *from* the manifest:
@@ -203,7 +203,7 @@ The format of the manifest will be subject to change whenever needed.
 It should be consumed only by scripts in the CPython repository.
 If a stable list is needed, a script can be added to generate it.
 
-The following wil be generated from the ABI manifest:
+The following will be generated from the ABI manifest:
 
 * Source for the Windows shared library, ``PC/python3dll.c``.
 * Input for documentation (see below).

pep-0653.rst

@@ -37,7 +37,7 @@ Precise semantics
 PEP 634 explicitly includes a section on undefined behavior.
 Large amounts of undefined behavior may be acceptable in a language like C,
 but in Python it should be kept to a minimum.
-Pattern matching in Python can be defined more precisely without loosing expressiveness or performance.
+Pattern matching in Python can be defined more precisely without losing expressiveness or performance.
 
 Improved control over class matching
 ------------------------------------
@@ -508,7 +508,7 @@ Implementations are allowed to make the following assumptions:
 * Mappings, that is any class for which ``__match_container__ == MATCH_MAPPING`` is not zero, will not capture the second argument of the ``get()`` method.
   So, the ``$sentinel`` value may be freely re-used.
 
-In fact, implementations are encouraged to make these assumptions, as it is likely to result in signficantly better performance.
+In fact, implementations are encouraged to make these assumptions, as it is likely to result in significantly better performance.
 
 
 Security Implications
@@ -544,7 +544,7 @@ Sequence patterns
 
 This is probably the most complex to optimize and the most profitable in terms of performance.
 Since each pattern can only match a range of lengths, often only a single length,
-the sequence of tests can be rewitten in as an explicit iteration over the sequence,
+the sequence of tests can be rewritten in as an explicit iteration over the sequence,
 attempting to match only those patterns that apply to that sequence length.
 
 For example:
@@ -642,7 +642,7 @@ The changes to the semantics can be summarized as:
   This make pattern matching a bit more robust and optimizable as ``__match_args__`` can be assumed to be immutable.
 * Selecting the kind of container patterns that can be matched uses ``cls.__match_container__`` instead of
   ``issubclass(cls, collections.abc.Mapping)`` and ``issubclass(cls, collections.abc.Sequence)``.
-* Allows classes to opt out of deconstruction altogether, if neccessary, but setting ``__match_class__ = 0``.
+* Allows classes to opt out of deconstruction altogether, if necessary, but setting ``__match_class__ = 0``.
 * The behavior when matching patterns is more precisely defined, but is otherwise unchanged.
 
 There are no changes to syntax. All examples given in the PEP 636 tutorial should continue to work as they do now.

pep-0654.rst

@@ -151,7 +151,7 @@ fields ``message`` and ``exceptions``. For example:
 The difference between them is that ``ExceptionGroup`` can only wrap
 ``Exception`` subclasses while ``BaseExceptionGroup`` can wrap any
 ``BaseException`` subclass. A factory method that inspects the nested
-execptions and selects between ``ExceptionGroup`` and ``BaseExceptionGroup``
+exceptions and selects between ``ExceptionGroup`` and ``BaseExceptionGroup``
 makes the choice automatic. In the rest of the document, when we refer to
 an exception group, we mean either an ``ExceptionGroup`` or a
 ``BaseExceptionGroup``. When it is necessary to make the distunction, we

pep-0656.rst

@@ -15,7 +15,7 @@ Resolution: https://discuss.python.org/t/7165/32
 Abstract
 ========
 
-This PEP proposes a new platfrom tag series ``musllinux`` for
+This PEP proposes a new platform tag series ``musllinux`` for
 binary Python package distributions for a Python installation that
 depends on musl on a Linux distribution. The tag works similarly to
 the "perennial manylinux" platform tags specified in :pep:`600`, but

pep-0659.rst

@@ -44,7 +44,7 @@ Both academic research and practical implementations have shown that a fast inte
 
 Typical optimizations for virtual machines are expensive, so a long "warm up" time is required 
 to gain confidence that the cost of optimization is justified.
-In order to get speed-ups rapidly, without noticable warmup times,
+In order to get speed-ups rapidly, without noticeable warmup times,
 the VM should speculate that specialization is justified even after a few executions of a function.
 To do that effectively, the interpreter must be able to optimize and deoptimize continually and very cheaply.
 
@@ -150,7 +150,7 @@ Quickened instructions will be stored in an array (it is neither necessary not d
 format as the original bytecode. Ancillary data will be stored in a separate array.
 
 Each instruction will use 0 or more data entries. Each instruction within a family must have the same amount of data allocated, although some
-instructions may not use all of it. Instructions that connot be specialized, e.g. ``POP_TOP``, do not need any entries.
+instructions may not use all of it. Instructions that cannot be specialized, e.g. ``POP_TOP``, do not need any entries.
 Experiments show that 25% to 30% of instructions can be usefully specialized.
 Different families will need different amounts of data, but most need 2 entries (16 bytes on a 64 bit machine).
 
@@ -172,7 +172,7 @@ CALL_FUNCTION
 
 The ``CALL_FUNCTION`` instruction calls the (N+1)th item on the stack with top N items on the stack as arguments.
 
-This is an obvious candidate for specialization. For example, the call in ``len(x)`` is repesented as the bytecode ``CALL_FUNCTION 1``.
+This is an obvious candidate for specialization. For example, the call in ``len(x)`` is represented as the bytecode ``CALL_FUNCTION 1``.
 In this case we would always expect the object ``len`` to be the function. We probably don't want to specialize for ``len``
 (although we might for ``type`` and ``isinstance``), but it would be beneficial to specialize for builtin functions taking a single argument.
 A fast check that the underlying function is a builtin function taking a single argument (``METHOD_O``) would allow us to avoid a

pep-0660.rst

@@ -43,7 +43,7 @@ Rationale
 PEP 517 deferred "Editable installs", meaning non-``setup.py``
 distributions lacked that feature. The only way to retain ``editable`` installs
 for these distributions was to provide a compatible ``setup.py develop``
-implementation. By definining an editable hook other build frontends gain
+implementation. By defining an editable hook other build frontends gain
 parity with ``setup.py``.
 
 Terminology and goals

pep-0662.rst

@@ -263,9 +263,9 @@ Frontend requirements
 
 The frontend must install the virtual wheel exactly as defined within
 :pep:`427`. Furthermore is responsible for also installing the files defined
-witin the ``editable.json`` file. The manner in which it does is left up to
+within the ``editable.json`` file. The manner in which it does is left up to
 the frontend, and is encouraged for the frontend to communicate with the user
-exactly the method choosen, and what limitations that solution will have.
+exactly the method chosen, and what limitations that solution will have.
 
 The frontend must create a ``direct_url.json`` file in the ``.dist-info``
 directory of the installed distribution, in compliance with PEP 610. The ``url``

pep-0663.txt

@@ -64,7 +64,7 @@ Note that format() already produces the correct output in 3.10, only str() needs
 updating.
 
 As much as possible, the ``str()`, ``repr()``, and ``format()`` of enum members
-should be standardized across the stardard library.
+should be standardized across the standard library.
 
 The repr() of Flag currently includes aliases, which it should not; fixing that
 will, of course, already change its ``repr()`` in certain cases.
@@ -182,7 +182,7 @@ Normal usage of enum members will not change: ``re.ASCII`` can still be used
 as ``re.ASCII`` and will still compare equal to ``256``.
 
 If the previous output needs to be maintained, for example to ensure
-compatibily between different Python versions, software projects will need to
+compatibility between different Python versions, software projects will need to
 create their own enum base class with the appropriate methods overridden.
 
 Note that by changing the ``str()`` of the drop-in category, we will actually

pep-0665.rst

@@ -236,7 +236,7 @@ Specifying a single file format can also increase the pace of innovation
 around installers and the generation of dependency graphs. By
 decoupling generating the dependency graph details from installation It
 allows for each area to grow and innovate independently. It also allows
-more flexibilty in tool selection on either end of the dependency graph
+more flexibility in tool selection on either end of the dependency graph
 and installation ends of this process.
 
 

pep-3101.txt

@@ -813,13 +813,13 @@ older system.
 References
 ==========
 
-.. [1] Python Library Reference - String formating operations
+.. [1] Python Library Reference - String formatting operations
        http://docs.python.org/library/stdtypes.html#string-formatting-operations
 
 .. [2] Python Library References - Template strings
        http://docs.python.org/library/string.html#string.Template
 
-.. [3] [Python-3000] String formating operations in python 3k
+.. [3] [Python-3000] String formatting operations in python 3k
        https://mail.python.org/pipermail/python-3000/2006-April/000285.html
 
 .. [4] Composite Formatting - [.Net Framework Developer's Guide]

pep-3110.txt

@@ -94,7 +94,7 @@ to ``NAME`` means that only valid identifiers can be used as
 ``except`` targets.
 
 Note that the grammar above always requires parenthesized tuples as
-exception clases. That way, the ambiguous ::
+exception classes. That way, the ambiguous ::
 
     except A, B:
 

pep-3116.txt

@@ -304,7 +304,7 @@ the cookie returned from ``.tell()``.
 
 
 ``TextIOBase`` implementations also provide several methods that are
-pass-throughs to the underlaying ``BufferedIOBase`` objects:
+pass-throughs to the underlying ``BufferedIOBase`` objects:
 
     ``.flush() -> None``
 

pep-3132.txt

@@ -65,7 +65,7 @@ will be assigned a list of all items from the iterable being unpacked
 that are not assigned to any of the mandatory expressions, or an
 empty list if there are no such items.
 
-For example, if ``seq`` is a slicable sequence, all the following
+For example, if ``seq`` is a sliceable sequence, all the following
 assignments are equivalent if ``seq`` has at least two elements::
 
     a, b, c = seq[0], list(seq[1:-1]), seq[-1]

pep-3135.txt

@@ -139,7 +139,7 @@ The proposal adds a dynamic attribute lookup to the super type, which will
 automatically determine the proper class and instance parameters. Each super
 attribute lookup identifies these parameters and performs the super lookup on
 the instance, as the current super implementation does with the explicit
-invokation of a super instance upon a class and instance.
+invocation of a super instance upon a class and instance.
 
 This proposal relies on sys._getframe(), which is not appropriate for anything
 except a prototype implementation.

pep-3141.txt

@@ -61,7 +61,7 @@ numbers are supported by this hierarchy. ::
         In short, those are: conversion to complex, bool(), .real, .imag,
         +, -, *, /, **, abs(), .conjugate(), ==, and !=.
 
-        If it is given heterogenous arguments, and doesn't have special
+        If it is given heterogeneous arguments, and doesn't have special
         knowledge about them, it should fall back to the builtin complex
         type as described below.
         """

pep-3149.txt

@@ -191,13 +191,13 @@ PEP 384 defines a stable ABI for extension modules.  In theory,
 universal adoption of PEP 384 would eliminate the need for this PEP
 because all extension modules could be compatible with any Python
 version.  In practice of course, it will be impossible to achieve
-universal adoption, and as described above, different built-time flags
+universal adoption, and as described above, different build-time flags
 still affect the ABI.  Thus even with a stable ABI, this PEP may still
 be necessary.  While a complete specification is reserved for PEP 384,
 here is a discussion of the relevant issues.
 
 PEP 384 describes a change to ``PyModule_Create()`` where ``3`` is
-passed as the API version if the extension was complied with
+passed as the API version if the extension was compiled with
 ``Py_LIMITED_API``.  This should be formalized into an official macro
 called ``PYTHON_ABI_VERSION`` to mirror ``PYTHON_API_VERSION``.  If
 and when the ABI changes in an incompatible way, this version number

pep-3150.txt

@@ -266,7 +266,7 @@ honour of preceding the implementation details:
 
 - decorators (which can greatly affect the behaviour of the created
   object, and were placed ahead of even the keyword and name as a matter
-  of practicality moreso than aesthetics)
+  of practicality more so than aesthetics)
 - the docstring (on the first line immediately following the header line)
 - parameters, default values and annotations for function definitions
 - parent classes, metaclass and optionally other details (depending on

pep-3156.txt

@@ -1778,7 +1778,7 @@ Convenience Utilities
 ---------------------
 
 A few functions and classes are provided to simplify the writing of
-basic stream-based clients and servers, such as FTP or HTTP.  Thes
+basic stream-based clients and servers, such as FTP or HTTP.  These
 are:
 
 - ``asyncio.open_connection(host, port)``: A wrapper for

pep_sphinx_extensions/pep_theme/static/style.css

@@ -10,7 +10,7 @@ white:
 #888
     blockquote left line
     header breadcrumbs separator
-    link underline (hovered/focussed)
+    link underline (hovered/focused)
 #ccc:
     scrollbar
 #ddd