PEP 621: reviewer feedback (#1714)

pep-0621.rst

@@ -446,9 +446,8 @@ provided via tooling later on.
   (i.e. ``dynamic`` is the only way to allow a tool to fill in
   metadata and the user must opt into the filling in).
 - Build back-ends MUST raise an error if the metadata specifies a
-  field in ``dynamic`` but is still unspecified in the final artifact
-  (i.e. the build back-end was unable to provide the data for a field
-  listed in ``dynamic``).
+  field in dynamic but the build back-end was unable to provide the
+  data for it.
 
 Example
 -------
@@ -519,12 +518,6 @@ statically define project metadata. Any security issues would stem
 from how tools consume the metadata and choose to act upon it.
 
 
-How to Teach This
-=================
-
-[How to teach users, new and experienced, how to apply the PEP to their work.]
-
-
 Reference Implementation
 ========================
 
@@ -669,12 +662,6 @@ things for build back-ends as they would have to make sure to traverse the full
 table structure rather than a single level and raising errors as appropriate on
 value types.
 
-Backfilling trove classifiers SHOULD occur instead of MAY happen
-----------------------------------------------------------------
-Originally this PEP said that tools SHOULD backfill appropriate trove classifiers.
-This was changed to say it MAY occur to emphasize it was entirely optional for
-build back-ends to implement.
-
 Using structured TOML dictionaries to specify dependencies
 ----------------------------------------------------------
 The format for specifying the dependencies of a project was the most
@@ -688,8 +675,8 @@ The authors briefly considered supporting both formats, but decided
 that it would lead to confusion as people would need to be familiar
 with two formats instead of just one.
 
-Require build backe-ends to update ``pyproject.toml`` when generating an sdist
-------------------------------------------------------------------------------
+Require build back-ends to update ``pyproject.toml`` when generating an sdist
+-----------------------------------------------------------------------------
 When this PEP was written, sdists did not require having static,
 canonical metadata like this PEP does. The idea was then considered to
 use this PEP as a way to get such metadata into sdists. In the end,