PEP 639: Implement @JelleZijlstra 's suggested editorial fixes

Co-authored-by: Jelle Zijlstra <[email protected]>

pep-0639.rst

@@ -140,9 +140,9 @@ including on `outdated and ambiguous PyPI classifiers <classifierissue_>`__,
 `the lack of clear, precise and standardized license metadata <pepissue_>`__.
 
 The current license classifiers address some common cases, and could
-theoretically be extended to include the full range of current SPDX
+be extended to include the full range of current SPDX
 identifiers while deprecating the many ambiguous classifiers (including some
-extremely popular and particularly problematic ones, such as
+popular and problematic ones, such as
 ``License :: OSI Approved :: BSD License``). However, this both requires a
 substantial amount of effort to duplicate the SPDX license list and keep
 it in sync, and is effectively a hard break in backward compatibility,
@@ -591,7 +591,7 @@ Add string value to ``license`` key
 
 A top-level string value is defined
 for the  ``license`` key in the ``[project]`` table,
-which specified to be a valid SPDX license expression,
+which is specified to be a valid SPDX license expression,
 as :ref:`defined previously <639-license-expression-definition>`.
 Its value maps to the ``License-Expression`` field in the core metadata.
 
@@ -696,7 +696,7 @@ Deprecate ``license`` key table subkeys
 '''''''''''''''''''''''''''''''''''''''
 
 Table values for the ``license`` key in the ``[project]`` table,
-including the ``text`` and ``file`` table subkeys, is now deprecated.
+including the ``text`` and ``file`` table subkeys, are now deprecated.
 If the new ``license-files`` key is present,
 build tools MUST raise an error if the ``license`` key is defined
 and has a value other than a single top-level string.
@@ -796,7 +796,7 @@ map to a single valid SPDX license identifier,
 allowing tools to infer the SPDX license identifier they correspond to,
 both for use when analyzing and auditing packages,
 and providing a semi-automated mechanism of filling the ``license`` key
-or the  the ``License-Expression`` field
+or the ``License-Expression`` field
 following the :ref:`specification above <639-spec-converting-metadata>`.
 
 Some legacy license classifiers intend to specify a particular license,
@@ -1254,7 +1254,7 @@ being dynamic and others static, and mapping to different core metadata fields.
 Furthermore, this leads to a conflict with marking the key as ``dynamic``
 (assuming that is intended to specify the ``[project]`` table keys,
 as that PEP seems to imprecisely imply,
-rather than core metadata fields), as either both would have
+rather than core metadata fields), as either or both would have
 to be treated as ``dynamic``.
 Grouping both license expressions and license files under the same key
 forces an "all or nothing" approach, and creates ambiguity as to user intent.
@@ -1316,7 +1316,7 @@ This was seen as clearer and more explicit for readers and writers,
 in line with the goals of this PEP.
 
 Additionally, while differences from existing tool formats (and core metadata
-field names) has precedent in :pep:`621`,
+field names) have precedent in :pep:`621`,
 using a key with an identical name as in most/all current tools
 to mean something different (and map to a different core metadata field),
 with distinct and incompatible syntax and semantics, does not,
@@ -1331,7 +1331,7 @@ from the ``License-Expression`` field as this PEP currently allows
 without it as ``license`` as dynamic
 (which would not be possible, since they both map to the same top-level key).
 
-However, community consensus was in favor instead using
+However, community consensus favored using
 the top-level string value of the existing ``license`` key,
 as :pep:`reserved for this purpose by PEP 621 <621#license>`:
 
@@ -1410,7 +1410,7 @@ as strictly speaking the ``license`` key is not (and cannot be) specified in
 ``pyproject.toml``, and satisfies a stricter interpretation of the letter
 of the previous :pep:`621` specification that this PEP revises.
 
-However, this doesn't seen to be necessary, because it is simply using the
+However, this doesn't seem to be necessary, because it is simply using the
 static, verbatim literal value of the ``license`` key, as specified
 strictly in this PEP. Therefore, any conforming tool can trivially,
 deterministically and unambiguously derive this using only the static data