PEP 639: Implement @JelleZijlstra 's suggested editorial fixes

pep-0639.rst

@@ -140,12 +140,13 @@ 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
-identifiers while deprecating the many ambiguous classifiers (including some
-extremely popular and particularly 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,
+be extended to include the full range of current SPDX identifiers
+while deprecating the many ambiguous classifiers
+(including some popular and problematic ones,
+such as ``License :: OSI Approved :: BSD License``).
+However, this requires a substantial amount of effort
+to duplicate the SPDX license list and keep it in sync.
+Furthermore, it is effectively a hard break in backward compatibility,
 forcing a huge proportion of package authors to immediately update to new
 classifiers (in most cases, with many possible choices that require closely
 examining the project's license) immediately when PyPI deprecates the old ones.
@@ -213,7 +214,7 @@ metadata story, this specification standardizes and builds upon
 existing practice in the `Setuptools <setuptoolsfiles_>`__ and
 `Wheel <wheelfiles_>`__ projects.
 Furthermore, an up-to-date version of the current draft of this PEP is
-`already successfully implemented <hatchimplementation_>`__  in the popular
+`already successfully implemented <hatchimplementation_>`__ in the popular
 PyPA `Hatch <hatch_>`__ packaging tool, and an earlier draft of the
 license files portion is `implemented in Setuptools <setuptoolspep639_>`__.
 
@@ -322,7 +323,7 @@ for the purposes of this PEP (``Syn:``).
   and the root directory that their paths, as recorded under the
   ``License-File`` core metadata fields, are relative to.
   Defined here to be the project root directory for source trees and source
-  distributions, and a subdirectory named  ``licenses`` of the directory
+  distributions, and a subdirectory named ``licenses`` of the directory
   containing the core metadata (i.e., the ``.dist-info/licenses``
   directory) for built distributions and installed projects.
 
@@ -590,8 +591,8 @@ 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,
+for the ``license`` key in the ``[project]`` table,
+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 +697,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 +797,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 +1255,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 +1317,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 +1332,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 +1411,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