Fix typos in PEPs using codespell (#3909)

Author: corneliusroemer

.codespell/exclude-file.txt

@@ -15,3 +15,7 @@
 
 explicitly declared using ``in``, ``out`` and ``inout`` keywords.
 |            |          |         |        |          |           | inout     |
+
+    >>> "abd\
+
+  * ``Is``, ``IsNot``, ``In``, and ``NotIn`` are not supported

.codespell/ignore-words.txt

@@ -6,10 +6,12 @@ arithmetics
 asend
 ba
 ccompiler
+checkin
 clos
 complies
 crate
 dedented
+discernable
 dota
 extraversion
 falsy
@@ -18,10 +20,13 @@ groth
 iif
 implementor
 implementors
+loath
 nd
 ned
 re-usable
 re-use
+re-used
+re-using
 recuse
 reenable
 referencable

.codespellrc

@@ -1,5 +1,5 @@
 [codespell]
-skip = ./.git
+skip = ./.git,./.codespellrc,./build,./ruff_cache,./.venv
 ignore-words = .codespell/ignore-words.txt
 exclude-file = .codespell/exclude-file.txt
 uri-ignore-words-list = daa,ist,searchin,theses

peps/pep-0100.rst

@@ -789,7 +789,7 @@ raw Unicode UTF-16 data (which the ``bf_getreadbuf`` returns), but
 instead tries to encode the Unicode object using the default
 encoding and then returns a pointer to the resulting string object
 (or raises an exception in case the conversion fails).  This was
-done in order to prevent accidentely writing binary data to an
+done in order to prevent accidentally writing binary data to an
 output stream which the other end might not recognize.
 
 This has the advantage of being able to write to output streams

peps/pep-0482.rst

@@ -75,7 +75,7 @@ ActionScript
 ------------
 
 ActionScript__ is a class-based, single inheritance,
-object-oriented superset of ECMAScript.  It supports inferfaces and
+object-oriented superset of ECMAScript.  It supports interfaces and
 strong runtime-checked static typing.  Compilation supports a “strict
 dialect” where type mismatches are reported at compile-time.
 

peps/pep-0501.rst

@@ -654,7 +654,7 @@ dynamic strings incorrectly. This requires a user to actually run a static analy
 
 If :pep:`675` tells you that you are violating a type check, it is up to the programmer to know how to handle the dynamic-ness of the string.
 This PEP provides a safer alternative to f-strings at runtime.
-If a user recieves a type-error, changing an existing f-string into a t-string could be an easy way to solve the problem.
+If a user receives a type-error, changing an existing f-string into a t-string could be an easy way to solve the problem.
 
 t-strings enable safer code by correctly escaping the dynamic sections of strings, while maintaining the static portions.
 

peps/pep-0540.rst

@@ -66,8 +66,8 @@ simply that the locale is frequently misconfigured.  An obvious solution
 suggests itself: ignore the locale encoding and use UTF-8.
 
 
-Passthough for undecodable bytes: surrogateescape
--------------------------------------------------
+Passthrough for undecodable bytes: surrogateescape
+--------------------------------------------------
 
 When decoding bytes from UTF-8 using the default ``strict`` error
 handler, Python 3 raises a ``UnicodeDecodeError`` on the first

peps/pep-0582.rst

@@ -233,7 +233,7 @@ significant issue, as it is unlikely that anyone would be able to write to
 
 For a ``__pypackages__`` directory in the current working directory, the
 interactive interpreter could be affected. However, this is not significantly
-different than the existing issue of someone having a ``math.py`` mdule in their
+different than the existing issue of someone having a ``math.py`` module in their
 current directory, and while (just like that case) it can cause user confusion,
 it does not introduce any new security implications.
 

peps/pep-0606.rst

@@ -117,7 +117,7 @@ more incompatible changes. The technical debt only steadily
 increases over time.
 
 With backward compatibility, it becomes possible to upgrade Python
-increamentally in a project, without having to fix all of the issues at once.
+incrementally in a project, without having to fix all of the issues at once.
 
 The "all-or-nothing" is a showstopper to port large Python 2 code bases
 to Python 3. The list of incompatible changes between Python 2 and

peps/pep-0626.rst

@@ -31,7 +31,7 @@ generated for all lines of code, and only for actual code.
 They should also be able to assume that the line number in ``f_lineno`` is correct.
 
 The current implementation mostly does this, but fails in a few cases.
-This requires workarounds in tooling and is a nuisance for alternative Python implementions.
+This requires workarounds in tooling and is a nuisance for alternative Python implementations.
 
 Having this guarantee also benefits implementers of CPython in the long term, as the current behaviour is not obvious and has some odd corner cases.
 

peps/pep-0639.rst

@@ -812,7 +812,7 @@ in a :ref:`separate page <639-rejected-ideas-details>`.
 Appendices
 ==========
 
-A list of auxilliary documents is provided:
+A list of auxiliary documents is provided:
 
 - Detailed :ref:`Licensing Examples <639-examples>`,
 - :ref:`User Scenarios <639-user-scenarios>`,

peps/pep-0639/appendix-rejected-ideas.rst

@@ -250,7 +250,7 @@ approach to specify their license files location. It was pointed out that
 it is easily possible to incorrectly assume that paths also support
 globs.
 
-Therfore, it was decided against this approach in favor of a flat array value
+Therefore, it was decided against this approach in favor of a flat array value
 which simplifies the specification and implementation,
 and more closely matches the configuration format of existing tools.
 The PEP recommends not to use other than alphanumerical symbols and dot

peps/pep-0697.rst

@@ -421,7 +421,7 @@ It will be an error to *not* use ``Py_RELATIVE_OFFSET`` with negative
 ``PyMember_SetOne``).
 
 CPython will adjust the offset and clear the ``Py_RELATIVE_OFFSET`` flag when
-intitializing a type.
+initializing a type.
 This means that:
 
 * the created type's ``tp_members`` will not match the input

peps/pep-0724.rst

@@ -173,7 +173,7 @@ user-defined type guard function changes in two ways.
             reveal_type(direction)  # "Literal[NW]"
 
 
-The type-theoretic rules for type narrowing are specificed in the following
+The type-theoretic rules for type narrowing are specified in the following
 table.
 
 ============ ======================= ===================
@@ -267,7 +267,7 @@ behavior. Such type guard functions could break with the new behavior.
             # "str", which is perhaps not what was intended.
             reveal_type(val)
 
-We think it is unlikley that such user-defined type guards exist in real-world
+We think it is unlikely that such user-defined type guards exist in real-world
 code. The mypy primer results didn't uncover any such cases.
 
 

peps/pep-0739.rst

@@ -554,7 +554,7 @@ One of the main requests in the discussion of this PEP was the inclusion of
 other kind of information, such as the ``site-packages`` path. It is the opinion
 of the PEP author that information regarding the Python environment should be
 provided by a separate file, creating the a clear separation between the build
-details, which should be immutable accross any interpreter instance, and details
+details, which should be immutable across any interpreter instance, and details
 that can change, such as environment details.
 
 

peps/pep-0741.rst

@@ -982,7 +982,7 @@ any proposal to add a granular initialization API around phases is
 effectively the opposite of what this PEP is trying to accomplish.
 Such API is more complicated, it requires adding new public structures
 and new public functions. It makes the Python initialization more
-complicated, rather than this PEP tries to unifiy existing APIs and make
+complicated, rather than this PEP tries to unify existing APIs and make
 them simpler (the opposite). Having multiple structures for similar
 purpose can lead to duplicate members, similar issue than duplicated
 members between existing ``PyPreConfig`` and ``PyConfig`` structures.

peps/pep-0744.rst

@@ -340,7 +340,7 @@ Choose the sections that best describe you:
 
     - ...in general, the JIT shouldn't be much of an inconvenience to you
       (depending on what you're trying to do). The micro-op interpreter isn't
-      going anywhere, and still offers a debugging experience similer to what
+      going anywhere, and still offers a debugging experience similar to what
       the main bytecode interpreter provides today. There is moderate likelihood
       that larger changes to the interpreter (such as adding new local
       variables, changing error handling and deoptimization logic, or changing

peps/pep-0747.rst

@@ -1024,7 +1024,7 @@ as an implicit ``TypeExpr`` value and be used directly in a context where a
 ``TypeExpr`` was expected. However making that possible would require making
 changes to the rules that type checkers use for the ``|`` operator. These rules
 are currently underspecified and would need to be make explicit first,
-before making changes to them. The PEP author is not sufficently motivated to
+before making changes to them. The PEP author is not sufficiently motivated to
 take on that specification work at the time of writing.
 
 

peps/pep-0751.rst

@@ -440,7 +440,7 @@ unless otherwise specified for the same reason.
 - Tables can be written inline.
 - Represents the files to potentially install for the package and version.
 - Entries in ``[[packages.files]]`` SHOULD be lexicographically sorted by
-  ``packages.files.name`` key to minimze changes in diffs.
+  ``packages.files.name`` key to minimize changes in diffs.
 
 
 ``packages.files.name``

peps/pep-8014.rst

@@ -132,7 +132,7 @@ The PEP author presents the PEP and the vote results to the Council of Elders.
 The council ponders two things:
 
 - the PEP gravity and its implications,
-- the measureable vote results (how many people voted, which individuals voted, what they voted).
+- the measurable vote results (how many people voted, which individuals voted, what they voted).
 
 They pronounce a tentative decision on whether the vote passed and this decision is published.