PEP 383, 421, 529, 689, 701, 706, 714, 715: Fix typos (#3202)

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.

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

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).
 

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:
 

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

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:

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.

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