Lint: Fix outstanding codespell spelling errors (#3129)

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: wookie184 <wookie1840@gmail.com>

.codespell/ignore-words.txt

@@ -1,4 +1,5 @@
 adaptee
+ancilliary
 ans
 arithmetics
 asend
@@ -15,5 +16,6 @@ nd
 ned
 recuse
 reenable
+referencable
 therefor
 warmup

pep-0011.txt

@@ -42,7 +42,7 @@ platform to be considered supported by CPython as well as providing a
 procedure to remove code for platforms with few or no CPython
 users.
 
-This PEP also lists what plaforms *are* supported by the CPython
+This PEP also lists what platforms *are* supported by the CPython
 interpreter. This lets people know what platforms are directly
 supported by the CPython development team.
 

pep-0285.txt

@@ -415,7 +415,7 @@ Resolved Issues
 
   since the bool is implicit in the "if".  Explicit is **not**
   better than implicit here, since the added verbiage impairs
-  redability and there's no other interpretation possible.  There
+  readability and there's no other interpretation possible.  There
   is, however, sometimes a reason to write
   ::
 

pep-0426.txt

@@ -1284,7 +1284,7 @@ Support for metadata extensions
 
 The new extension effectively allows sections of the metadata
 namespace to be delegated to other projects, while preserving a
-standard overal format metadata format for easy of processing by
+standard overall format metadata format for easy of processing by
 distribution tools that do not support a particular extension.
 
 It also works well in combination with the new ``build`` extra

pep-0526.txt

@@ -464,7 +464,7 @@ culprit, is accepted by the Python interpreter without questioning it
 
 The recommended way of getting annotations at runtime is by using
 ``typing.get_type_hints`` function; as with all dunder attributes,
-any undocummented use of ``__annotations__`` is subject to breakage
+any undocumented use of ``__annotations__`` is subject to breakage
 without warning::
 
   from typing import Dict, ClassVar, get_type_hints

pep-0554.rst

@@ -478,7 +478,7 @@ each with different goals.  Most center on correctness and usability.
 One class of concurrency models focuses on isolated threads of
 execution that interoperate through some message passing scheme.  A
 notable example is Communicating Sequential Processes [CSP]_ (upon
-which Go's concurrency is roughly based).  The inteded isolation
+which Go's concurrency is roughly based).  The intended isolation
 inherent to CPython's interpreters makes them well-suited
 to this approach.
 

pep-0582.rst

@@ -46,7 +46,7 @@ advanced concepts.
 Furthermore, standalone Python applications usually need 3rd party libraries to
 function. Typically, they are either designed to be run from a virtual environment,
 where the dependencies are installed into the environment alongside the application,
-or they bundle their depenencies in a subdirectory, and modify ``sys.path`` at
+or they bundle their dependencies in a subdirectory, and modify ``sys.path`` at
 application startup. Virtual environments, while a common and effective solution
 (used, for example, by the ``pipx`` tool), are somewhat awkward to set up and manage,
 and are not relocatable. On the other hand, manual manipulation of ``sys.path`` is

pep-0622.rst

@@ -2107,7 +2107,7 @@ the fact that, because of the way names are bound, there are no real
 constants in Python. It also meant that the ``__match__`` method would
 have to re-implement much of the logic of matching which would otherwise
 be implemented in C code in the Python VM. As a result, this option would
-perform poorly compared to an equilvalent ``if``-statement.
+perform poorly compared to an equivalent ``if``-statement.
 
 The simpler protocol suffered from the fact that although it was more
 performant, it was much less flexible, and did not allow for many of

pep-0642.rst

@@ -1699,7 +1699,7 @@ pattern caching rule, where the number of times the constraint expression
 actually gets evaluated will be implementation dependent. Even here, the PEP
 takes the view of letting users write nonsense if they really want to.
 
-Aside from the recenty updated decorator expressions, another situation where
+Aside from the recently updated decorator expressions, another situation where
 Python's formal syntax offers full freedom of expression that is almost never
 used in practice is in ``except`` clauses: the exceptions to match against
 almost always take the form of a simple name, a dotted name, or a tuple of

pep-0652.rst

@@ -242,7 +242,7 @@ The initial Stable ABI manifest will include:
 Items that are no longer in CPython when this PEP is accepted will be removed
 from the list.
 
-Additional items may be aded to the initial manifest according to
+Additional items may be added to the initial manifest according to
 the checklist below.
 
 

pep-0653.rst

@@ -593,7 +593,7 @@ Can be compiled roughly as:
 Mapping patterns
 ''''''''''''''''
 
-The best stategy here is probably to form a decision tree based on the size of the mapping and which keys are present.
+The best strategy here is probably to form a decision tree based on the size of the mapping and which keys are present.
 There is no point repeatedly testing for the presence of a key.
 For example::
 

pep-0665.rst

@@ -55,7 +55,7 @@ reproducibility across multiple platforms. Examples of this are
 ``package-lock.json`` from npm_, ``Poetry.lock`` from Poetry_, etc.
 
 *Locking* is the act of taking the input of the packages an app
-depends on and producting a lock file from that.
+depends on and producing a lock file from that.
 
 A *locker* is a tool which produces a lock file.
 

pep-0669.rst

@@ -422,7 +422,7 @@ they should be fairly inexpensive.
 Memory Consumption
 ''''''''''''''''''
 
-When not in use, this PEP will have a neglible change on memory consumption.
+When not in use, this PEP will have a negligible change on memory consumption.
 
 How memory is used is very much an implementation detail.
 However, we expect that for 3.12 the additional memory consumption per

pep-0670.rst

@@ -521,7 +521,7 @@ Debug build
 
 Performance in debug builds *can* suffer when macros are converted to
 functions. This is compensated by better debuggability: debuggers can
-retreive function names, set breakpoints inside functions, etc.
+retrieve function names, set breakpoints inside functions, etc.
 
 On Windows, when Python is built in debug mode by Visual Studio, static
 inline functions are not inlined.

pep-0674.rst

@@ -401,7 +401,7 @@ The HPy project
 
 The hope with the HPy project is to provide a C API that is close
 to the original API—to make porting easy—and have it perform as close to
-the existing API as possible. At the same time, HPy is sufficently
+the existing API as possible. At the same time, HPy is sufficiently
 removed to be a good "C extension API" (as opposed to a stable subset of
 the CPython implementation API) that does not leak implementation
 details. To ensure this latter property, the HPy project tries to

pep-0677.rst

@@ -1020,7 +1020,7 @@ In order to allow both ``->`` and ``|`` tokens in type expressions we
 had to choose precedence. In the current proposal, this is a function
 returning an optional boolean::
 
-    (int, str) -> bool | None  # equivalent ot (int, str) -> (bool | None)
+    (int, str) -> bool | None  # equivalent to (int, str) -> (bool | None)
 
 We considered having ``->`` bind tighter so that instead the expression
 would parse as ``((int, str) -> bool) | None``. There are two advantages
@@ -1115,7 +1115,7 @@ that refers to type parameters rather than callable parameters.
 Using the plain return type in ``__args__`` for async types
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-It is debatable whether we are required to preserve backward compatiblity
+It is debatable whether we are required to preserve backward compatibility
 of ``__args__`` for async callable types like ``async (int) -> str``. The
 reason is that one could argue they are not expressible directly
 using ``typing.Callable``, and therefore it would be fine to set

pep-0683.rst

@@ -24,7 +24,7 @@ The PEP was accepted with conditions:
   (reset the immortal refcount in ``tp_dealloc()``)
 * types without this may not be immortalized (in CPython's code)
 * the PEP must be updated with final benchmark results once
-  the implmentation is finalized
+  the implementation is finalized
 * we will have one last round of discussion about those results at that point
 
 
@@ -703,7 +703,7 @@ specialize for immortal objects in the eval loop
 ''''''''''''''''''''''''''''''''''''''''''''''''
 
 There are opportunities to optimize operations in the eval loop
-involving speicific known immortal objects (e.g. ``None``).  The
+involving specific known immortal objects (e.g. ``None``).  The
 general mechanism is described in :pep:`659`.  Also see `Pyston`_.
 
 other possibilities

pep-0684.rst

@@ -671,7 +671,7 @@ Reference Implementation
 Open Issues
 ===========
 
-* Are we okay to require "mem" and "object" allcoators to be thread-safe?
+* Are we okay to require "mem" and "object" allocators to be thread-safe?
 * How would a per-interpreter tracemalloc module relate to global allocators?
 * Would the faulthandler module be limited to the main interpreter
   (like the signal module) or would we leak that global state between

pep-0689.rst

@@ -39,7 +39,7 @@ The Python C-API is currently divided into `three stability tiers <https://devgu
   <387>`, and requires deprecation warnings before changes
 - Internal (private) API, which can change at any time.
 
-Tools requring access to CPython internals (e.g. advanced
+Tools requiring access to CPython internals (e.g. advanced
 debuggers and JIT compilers) are often built for minor series releases
 of CPython, and assume that the C-API internals used do not change
 in patch releases. To support these tools, we need a tier between the
@@ -130,7 +130,7 @@ Several rules for dealing with the unstable tier will be introduced:
    this name.
 
    In the following cases, an incompatible change (and thus removing the
-   deprecated name) is allowed without an SC exeption, as if the function was
+   deprecated name) is allowed without an SC exception, as if the function was
    already part of the Unstable tier:
 
    -  Any API introduced before Python 3.12 that is *documented* to be less

pep-0690.rst

@@ -293,7 +293,7 @@ necessary metadata to execute the import later.
 A new boolean flag in ``PyDictKeysObject`` (``dk_lazy_imports``) is set to
 signal that this particular dictionary may contain lazy import objects. This
 flag is only used to efficiently resolve all lazy objects in "bulk" operations,
-when a dictionay may contain lazy objects.
+when a dictionary may contain lazy objects.
 
 Anytime a key is looked up in a dictionary to extract its value, the
 value is checked to see if it is a lazy import object. If so, the lazy object

pep-0691.rst

@@ -84,7 +84,7 @@ Goals
   increase the amount of HTTP requests an installer must do in order to function.
   Ideally it will require 0 additional requests, but if needed it may require one
   or two additional requests (total, not per dependency).
-- **Minimal additional unique reponses.** Due to the nature of how large
+- **Minimal additional unique responses.** Due to the nature of how large
   repositories like PyPI cache responses, this PEP should not introduce a
   significantly or combinatorially large number of additional unique responses
   that the repository may produce.

pep-0701.rst

@@ -376,7 +376,7 @@ tokens:
      is encountered, emit a token for the closing bracket and go to step 2.
 
 3. Push a new tokenizer mode to the tokenizer mode stack for "Regular Python
-   tokenization withing f-string" and proceed to tokenize with it. This mode
+   tokenization within f-string" and proceed to tokenize with it. This mode
    tokenizes as the "Regular Python tokenization" until a ``!``, ``:``, ``=``
    character is encountered or if a ``}`` character is encountered with the same
    level of nesting as the opening bracket token that was pushed when we enter the
@@ -436,7 +436,7 @@ as these should be taken into consideration when accepting or rejecting this PEP
 
 Some of these objections include:
 
-* Many people find quote reuse withing the same string confusing and hard to read. This is because
+* Many people find quote reuse within the same string confusing and hard to read. This is because
   allowing quote reuse will violate a current property of Python as it stands today: the fact that
   strings are fully delimited by two consecutive pairs of the same kind of quote, which by itself is a very simple rule.
   One of the reasons quote reuse may be harder for humans to parse, leading to less readable

pep-0706.rst

@@ -538,7 +538,7 @@ How to Teach This
 
 The API, usage notes and tips for further verification will be added to
 the documentation.
-These should be usable for users who are familiar wth archives in general, but
+These should be usable for users who are familiar with archives in general, but
 not with the specifics of UNIX filesystems nor the related security issues.
 
 
@@ -569,7 +569,7 @@ Add absolute_path option to tarfile
 
 Issue `gh-73974`_ asks for adding an ``absolute_path`` option to extraction
 methods. This would be a minimal change to formally resolve `CVE-2007-4559`_.
-It doesn't go far enough to protect the unaware, nor to empower the dilligent
+It doesn't go far enough to protect the unaware, nor to empower the diligent
 and curious.
 
 Other names for the ``'tar'`` filter

pep-0708.rst

@@ -123,7 +123,7 @@ rely on them are forced to set up multiple repositories and have their users
 manually configure them to get the correct binaries for their platform, GPU,
 CPU, etc.
 
-This use case is similiar to the first, but the important difference that makes
+This use case is similar to the first, but the important difference that makes
 it a distinct use case on it's own is who is providing the information and what
 their level of trust is.