Fix typos flagged by codespell

peps/pep-0739.rst

@@ -559,7 +559,7 @@ below, which is rendered in an human-readable format here.
         Either an absolute path, or a path relative to ``base_prefix``.
 
         This field **MUST** be present if the Python installation
-        provides a dynamic ``libpython`` library targetting the Stable
+        provides a dynamic ``libpython`` library targeting the Stable
         ABI, otherwise this entry will be missing.
 
         If this key is present ``dynamic`` **MUST** also be set.
@@ -725,7 +725,7 @@ provided by a separate file.
 Including environment-specific data in the config file means that it would be
 environment-specific, so virtual environments would need their own config file.
 This is problematic because virtual environments survive updates of the base
-Python installation, creating the possibily for the static config file to be
+Python installation, creating the possibility for the static config file to be
 outdated, and making its data unreliable, which defeats its purpose.
 
 The proposed solution, partially implemented in this PEP, is to have a

peps/pep-0739/python-build-info-v1.0.schema.json

@@ -206,7 +206,7 @@
         },
         "dynamic_stableabi": {
           "type": "string",
-          "description": "The path to the dynamic ``libpython`` library for the stable ABI.\n\nEither an absolute path, or a path relative to ``base_prefix``.\n\nThis field **MUST** be present if the Python installation provides a dynamic ``libpython`` library targetting the Stable ABI, otherwise this entry will be missing.\n\nIf this key is present ``dynamic`` **MUST** also be set.",
+          "description": "The path to the dynamic ``libpython`` library for the stable ABI.\n\nEither an absolute path, or a path relative to ``base_prefix``.\n\nThis field **MUST** be present if the Python installation provides a dynamic ``libpython`` library targeting the Stable ABI, otherwise this entry will be missing.\n\nIf this key is present ``dynamic`` **MUST** also be set.",
           "examples": [
             "/usr/lib/libpython3.so",
             "lib/libpython3.so"

peps/pep-0755.rst

@@ -280,7 +280,7 @@ There is no indicator for projects that are tied to a
 this is the most common scenario.
 
 If there was an indicator, it would not be a check mark or similar as NuGet
-chose because it may mistakingly convey that there are associated security
+chose because it may mistakenly convey that there are associated security
 guarantees inherent to the use of the package. Additionally, some social media
 platforms use a check mark for verified users which may cause confusion.
 

peps/pep-0773.rst

@@ -1625,7 +1625,7 @@ Make every version a Windows Store package
 It is possible to release each version to the Windows Store as we currently do,
 but make them unlisted and rely on an installer (potentially PyManager, WinGet,
 or another tool that can install Store packages). This would avoid the risk of
-overwhelming the user, while greatly simplifying our own reponsibilities for
+overwhelming the user, while greatly simplifying our own responsibilities for
 package management.
 
 This approach would leave a significant burden on whichever contributor has

peps/pep-0777.rst

@@ -353,7 +353,7 @@ Why not Specify Wheel 2.0 In This PEP?
 There are *many* features that could be included as part of wheel 2.0, but this
 PEP does not cover them. The goal of this PEP is to define a compatibility
 story for the wheel file format. Changes that do not pertain to compatibility
-for wheel versions do not need to be in this PEP, and should be introducted
+for wheel versions do not need to be in this PEP, and should be introduced
 in follow-up PEPs defining new wheel features.
 
 Discussion Topics

peps/pep-0783.rst

@@ -256,7 +256,7 @@ Alternative Options for the Platform Tag
 
 No patch version
     We hope never to need the patch version, but it's good to be prepared for
-    unforseen problems.
+    unforeseen problems.
 
 How to Teach This
 =================

peps/pep-0793.rst

@@ -513,7 +513,7 @@ wrappers, the :ref:`pep793-shim` below may be more useful.
    Later in this guide, you'll set the token to *be* the existing
    ``PyModuleDef`` structure.
 
-   (You may skip this step if targetting Python versions that don't expose
+   (You may skip this step if targeting Python versions that don't expose
    ``PyType_GetModuleByToken``, since ``PyType_GetModuleByDef`` is
    backwards-compatible.)
 

peps/pep-0793/examplemodule.c

@@ -6,7 +6,7 @@ Example module with C-level module-global state, and
   PyType_GetModuleByToken)
 
 Once compiled and renamed to not include a version tag (for example
-examplemodule.so on Linux), this will run succesfully on both regular
+examplemodule.so on Linux), this will run successfully on both regular
 and free-threaded builds.
 
 Python usage:

peps/pep-0797.rst

@@ -301,7 +301,7 @@ in the wrapped object's interpreter. To visualize:
     interp = interpreters.create()
     interp.prepare_main(proxy=proxy)
 
-    # This prints out [], because the wrapepd object must be invisible to this
+    # This prints out [], because the wrapped object must be invisible to this
     # interpreter.
     interp.exec("import gc; print(gc.get_referents(proxy))")
 

peps/pep-0820.rst

@@ -54,7 +54,7 @@ change the details.
 
 Both structures contain a *slots* field, essentially an array of
 `tagged unions <https://en.wikipedia.org/wiki/Tagged_union>`__
-(``void`` pointers taged with an ``int`` ID).
+(``void`` pointers tagged with an ``int`` ID).
 This allows for future expansion.
 
 In :pep:`793`, new module creation API was added.

release_management/python-releases.toml

@@ -2,7 +2,7 @@
 # CC0-1.0-Universal licence, whichever is more permissive.
 #
 # This document contains the history of every release of the Python project,
-# and specifically the CPython intepreter. The data in this file were initially
+# and specifically the CPython interpreter. The data in this file were initially
 # compiled in 2025 by Adam Turner, with information primarily sourced from the
 # release PEPs and supplemented by the 'releases' section of www.python.org.
 #