From 0e422008edb83b34bcb486ae35f3fffe08f2384f Mon Sep 17 00:00:00 2001 From: Uriya Harpeness <53301931+UriyaHarpeness@users.noreply.github.com> Date: Fri, 14 Jul 2023 19:49:20 +0300 Subject: [PATCH] PEP 383, 421, 529, 689, 701, 706, 714, 715: Fix typos (#3202) --- pep-0383.txt | 2 +- pep-0421.txt | 4 ++-- pep-0529.txt | 2 +- pep-0689.rst | 2 +- pep-0701.rst | 2 +- pep-0706.rst | 2 +- pep-0714.rst | 6 +++--- pep-0715.rst | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/pep-0383.txt b/pep-0383.txt index f5a2075b5..e13c7b953 100644 --- a/pep-0383.txt +++ b/pep-0383.txt @@ -100,7 +100,7 @@ has the limitation that chosen representation only "works" if the data get converted back to bytes with the surrogateescape error handler also. Encoding the data with the locale's encoding and the (default) strict error handler will raise an exception, encoding them with UTF-8 -will produce non-sensical data. +will produce nonsensical data. Data obtained from other sources may conflict with data produced by this PEP. Dealing with such conflicts is out of scope of the PEP. diff --git a/pep-0421.txt b/pep-0421.txt index 4a6b3648e..e1287ea30 100644 --- a/pep-0421.txt +++ b/pep-0421.txt @@ -193,7 +193,7 @@ As already noted in `Version Format`_, values in ``sys.implementation`` are intended for use by the standard library. Constraining those values, essentially specifying an API for them, allows them to be used consistently, regardless of how they are -otherwise implemented. However, care should be take to not +otherwise implemented. However, care should be taken to not over-specify the constraints. @@ -375,7 +375,7 @@ The Bigger Picture ================== It's worth noting again that this PEP is a small part of a larger -on-going effort to identify the implementation-specific parts of Python +ongoing effort to identify the implementation-specific parts of Python and mitigate their impact on alternate implementations. ``sys.implementation`` is a focal point for implementation-specific diff --git a/pep-0529.txt b/pep-0529.txt index 2e7264c1e..13c32f50c 100644 --- a/pep-0529.txt +++ b/pep-0529.txt @@ -126,7 +126,7 @@ The use of utf-8 will not be configurable, except for the provision of a "legacy mode" flag to revert to the previous behaviour. The ``surrogateescape`` error mode does not apply here, as the concern is not -about retaining non-sensical bytes. Any path returned from the operating system +about retaining nonsensical bytes. Any path returned from the operating system will be valid Unicode, while invalid paths created by the user should raise a decoding error (currently these would raise ``OSError`` or a subclass). diff --git a/pep-0689.rst b/pep-0689.rst index 7928bb2ae..89d5bb01e 100644 --- a/pep-0689.rst +++ b/pep-0689.rst @@ -104,7 +104,7 @@ APIs (functions, types, etc.) in this tier will named with the ``PyUnstable_`` prefix, with no leading underscore. They will be declared in headers used for public API (``Include/*.h``, -rather than in a subdirectory like ``Include/ustable/``). +rather than in a subdirectory like ``Include/unstable/``). Several rules for dealing with the unstable tier will be introduced: diff --git a/pep-0701.rst b/pep-0701.rst index 4ed89e9e3..c7bd90c69 100644 --- a/pep-0701.rst +++ b/pep-0701.rst @@ -229,7 +229,7 @@ The new tokens (``FSTRING_START``, ``FSTRING_MIDDLE``, ``FSTRING_END``) are defi :ref:`later in this document <701-new-tokens>`. This PEP leaves up to the implementation the level of f-string nesting allowed -(f-strings withing the expression parts of other f-strings) but **specifies a +(f-strings within the expression parts of other f-strings) but **specifies a lower bound of 5 levels of nesting**. This is to ensure that users can have a reasonable expectation of being able to nest f-strings with "reasonable" depth. This PEP implies that limiting nesting is **not part of the language diff --git a/pep-0706.rst b/pep-0706.rst index 76a704235..5585a809b 100644 --- a/pep-0706.rst +++ b/pep-0706.rst @@ -346,7 +346,7 @@ argument/attribute, which specifies how errors are handled: so, for example, you still get ``TypeError`` if you pass ``None`` as the destination path. - With ``errorlevel=1`` (the default), all *non-fatal* errors are ignored. - (They may be logged to ``sys.stderr`` by setting the *degug* + (They may be logged to ``sys.stderr`` by setting the *debug* argument/attribute.) Which errors are *non-fatal* is not defined in documentation, but code treats ``ExtractionError`` as such. Specifically, it's these issues: diff --git a/pep-0714.rst b/pep-0714.rst index 75ab8d65a..00542d5e5 100644 --- a/pep-0714.rst +++ b/pep-0714.rst @@ -123,7 +123,7 @@ read the :pep:`658` metadata from the key ``data-core-metadata`` if it is present. They **MAY** optionally use the legacy ``data-dist-info-metadata`` if it is present but ``data-core-metadata`` is not. -Clients consuming the JSON represenation of the Simple API **MUST** read the +Clients consuming the JSON representation of the Simple API **MUST** read the :pep:`658` metadata from the key ``core-metadata`` if it is present. They **MAY** optionally use the legacy ``dist-info-metadata`` key if it is present but ``core-metadata`` is not. @@ -222,7 +222,7 @@ difficult to implement in a reasonable way. Only change the JSON key ------------------------ -The bug in pip only affects the JSON represenation of the Simple API, so we only +The bug in pip only affects the JSON representation of the Simple API, so we only *need* to actually change the key in the JSON, and we could leave the existing HTML keys alone. @@ -253,7 +253,7 @@ We recommend that servers *only* emit the newer keys, particularly for the JSON representation of the Simple API since the bug itself only affected JSON. Servers that wish to support :pep:`658` in clients that use HTML and have it -implemened, can safely emit both keys *only* in HTML. +implemented, can safely emit both keys *only* in HTML. Servers should not emit the old keys in JSON unless they know that no broken versions of pip will be used to access their server. diff --git a/pep-0715.rst b/pep-0715.rst index 0fda9b358..8a99096b0 100644 --- a/pep-0715.rst +++ b/pep-0715.rst @@ -71,7 +71,7 @@ Some observations from that issue: Given the above, this PEP proposes the removal of the ``bdist_egg`` format under the same justifications presented in :pep:`527`, namely: -* Egg distributions are of of limited use to the broader ecosystem and +* Egg distributions are of limited use to the broader ecosystem and therefore represent a non-reciprocal maintenance burden; * Having an additional built distribution format is confusing to end users, who may