Reflow

Author: brettcannon

peps/pep-0794.rst

@@ -76,13 +76,13 @@ every project release and look at what files are provided via the
 :ref:`packaging:binary-distribution-format`, but that's a lot of CPU and
 bandwidth for something that is static information (although tricks can be
 used to lessen the data requests such as using HTTP range requests to only
-read the table of contents of the zip file). This sort of calculation is also currently repeated by everyone
-independently instead of having the metadata hosted by a central index server
-like PyPI. It also doesn't work for sdists as the structure of the wheel
-isn't known yet, and so inferring the structure of the code installed isn't
-known yet. As well, these solutions are not necessarily accurate as it is
-based on inference instead of being explicitly provided by the project
-owners.
+read the table of contents of the zip file). This sort of calculation is also
+currently repeated by everyone independently instead of having the metadata
+hosted by a central index server like PyPI. It also doesn't work for sdists as
+the structure of the wheel isn't known yet, and so inferring the structure of
+the code installed isn't known yet. As well, these solutions are not
+necessarily accurate as it is based on inference instead of being explicitly
+provided by the project owners.
 
 
 Specification
@@ -126,8 +126,8 @@ imported by anyone and can "take up space" in the namespace of the
 environment. Tools consuming the metadata SHOULD consider the information
 provided in ``Import-Name`` as accurate, but not exhaustive.
 
-The :ref:`declaring-project-metadata` will gain an ``import-names`` key. It will
-be an array of strings that stores what will be written out to
+The :ref:`declaring-project-metadata` will gain an ``import-names`` key. It
+will be an array of strings that stores what will be written out to
 ``Import-Name``. Build back-ends MAY support dynamically calculating the
 value on the user's behalf if desired, if the user declares the key to be
 dynamic.