diff --git a/.codespell/ignore-words.txt b/.codespell/ignore-words.txt index 9456130950a..20a642ae936 100644 --- a/.codespell/ignore-words.txt +++ b/.codespell/ignore-words.txt @@ -1,4 +1,5 @@ adaptee +ancilliary ans arithmetics asend @@ -15,5 +16,6 @@ nd ned recuse reenable +referencable therefor warmup diff --git a/pep-0011.txt b/pep-0011.txt index 2ba4151bbe5..ffbd2e76659 100644 --- a/pep-0011.txt +++ b/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. diff --git a/pep-0285.txt b/pep-0285.txt index 8de75912d01..a69d495b214 100644 --- a/pep-0285.txt +++ b/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 :: diff --git a/pep-0426.txt b/pep-0426.txt index 91f47d8f527..5163310de18 100644 --- a/pep-0426.txt +++ b/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 diff --git a/pep-0526.txt b/pep-0526.txt index d13f4f8c487..0aa2e20581d 100644 --- a/pep-0526.txt +++ b/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 diff --git a/pep-0554.rst b/pep-0554.rst index 8fa2f90bb7f..08fcb0fcbfd 100644 --- a/pep-0554.rst +++ b/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. diff --git a/pep-0582.rst b/pep-0582.rst index 75c846d19ca..d21c30b0eab 100644 --- a/pep-0582.rst +++ b/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 diff --git a/pep-0622.rst b/pep-0622.rst index 075535d7499..bf061cf6296 100644 --- a/pep-0622.rst +++ b/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 diff --git a/pep-0642.rst b/pep-0642.rst index 8742804dc89..601e7c4df54 100644 --- a/pep-0642.rst +++ b/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 diff --git a/pep-0652.rst b/pep-0652.rst index 5f509aeaf8c..f15ab8e0c83 100644 --- a/pep-0652.rst +++ b/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. diff --git a/pep-0653.rst b/pep-0653.rst index 2c80548ebdf..7e81a306b5e 100644 --- a/pep-0653.rst +++ b/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:: diff --git a/pep-0665.rst b/pep-0665.rst index ac984660b0d..ec999f54f7a 100644 --- a/pep-0665.rst +++ b/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. diff --git a/pep-0669.rst b/pep-0669.rst index 8648da333c3..e2851a871aa 100644 --- a/pep-0669.rst +++ b/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 diff --git a/pep-0670.rst b/pep-0670.rst index f5fadb94aac..a9298a682d2 100644 --- a/pep-0670.rst +++ b/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. diff --git a/pep-0674.rst b/pep-0674.rst index f383f80c1c1..c87574a4d64 100644 --- a/pep-0674.rst +++ b/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 diff --git a/pep-0677.rst b/pep-0677.rst index 4442840080a..a55eb804969 100644 --- a/pep-0677.rst +++ b/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 diff --git a/pep-0683.rst b/pep-0683.rst index 01a1461d005..6abdc1b46c7 100644 --- a/pep-0683.rst +++ b/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 diff --git a/pep-0684.rst b/pep-0684.rst index 6a1dd5b70c4..c8964309c16 100644 --- a/pep-0684.rst +++ b/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 diff --git a/pep-0689.rst b/pep-0689.rst index be2d26f9e24..7775f07de57 100644 --- a/pep-0689.rst +++ b/pep-0689.rst @@ -39,7 +39,7 @@ The Python C-API is currently divided into `three stability tiers `, 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 diff --git a/pep-0690.rst b/pep-0690.rst index d1a1d805226..3df31c96194 100644 --- a/pep-0690.rst +++ b/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 diff --git a/pep-0691.rst b/pep-0691.rst index 4df4bfe69e8..0de7cfd7fb3 100644 --- a/pep-0691.rst +++ b/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. diff --git a/pep-0701.rst b/pep-0701.rst index 9858e1f08be..75beff72976 100644 --- a/pep-0701.rst +++ b/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 diff --git a/pep-0706.rst b/pep-0706.rst index 6e2df4e602a..156d73c6a61 100644 --- a/pep-0706.rst +++ b/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 diff --git a/pep-0708.rst b/pep-0708.rst index 75e1db10675..4b8298799c9 100644 --- a/pep-0708.rst +++ b/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.