Remove double spaces introduced while reflowing

Remove accidental double spaces that vim's `gq` introduced while I was
reflowing the text.  Thanks to @konstin for noticing.

Signed-off-by: Michał Górny <mgorny@quansight.com>

Author: mgorny

peps/pep-0817.rst

@@ -32,7 +32,7 @@ the scientific computing, artificial intelligence (AI), machine learning
 (ML), and high-performance computing (HPC) communities.
 
 This PEP proposes "Wheel Variants", an extension to the
-:doc:`packaging:specifications/binary-distribution-format`.  This
+:doc:`packaging:specifications/binary-distribution-format`. This
 extension introduces a mechanism for package maintainers to declare
 multiple build variants for the same package version, while allowing
 installers to automatically select the most appropriate variant based on
@@ -101,14 +101,14 @@ to significant performance improvement.
               various targets. The first two bars are labeled "yum
               (2018.8)" and "generic (SSE2)", reach about 1.0 ns/day and
               are both marked as "SSE2". The next bar is labeled
-              "ivybridge" ("AVX") and reaches almost 1.5 ns/day.  Two
+              "ivybridge" ("AVX") and reaches almost 1.5 ns/day. Two
               following bars are labeled "haswell" and "broadwell" (both
-              "AVX2") and exceed 1.5 ns/day slightly.  The last two bars
+              "AVX2") and exceed 1.5 ns/day slightly. The last two bars
               are labeled "skylake_avx512" and "cascadelake" (both
               "AVX512") and reach almost 2.0 ns/day.
 
         Performance of GROMACS 2020.1 built for different generations of
-        CPUs.  Vertical axis shows performance expressed in ns/day, a
+        CPUs. Vertical axis shows performance expressed in ns/day, a
         GROMACS-specific measure of simulation speed (higher is better).
 
     Compiling `GROMACS <https://www.gromacs.org/>`_ for architectures
@@ -270,7 +270,7 @@ the way package upgrades are ordered.
 
 An additional limitation of this approach is that publishing a new
 release synchronously across multiple package names is not currently
-possible.  :pep:`694` proposes adding such a mechanism for multiple
+possible. :pep:`694` proposes adding such a mechanism for multiple
 wheels within a single package, but extending it to multiple packages is
 not a goal.
 
@@ -771,7 +771,7 @@ Variant properties serve the purpose of expressing the characteristics
 of the variant. Unlike platform compatibility tags, they are stored in
 the variant metadata and therefore do not affect the wheel filename
 length. They follow a hierarchical key-value design, with the key
-further broken into a namespace and a feature name.  Namespaces are used
+further broken into a namespace and a feature name. Namespaces are used
 to group features defined by a single provider, and to avoid conflicts
 should multiple providers define a feature with the same name. This
 permits independent governance and evolution of every namespace.
@@ -924,7 +924,7 @@ This setup could be improved using GPU/XPU plugins that query the
 installed runtime version and installed GPUs/XPUs to filter out the
 wheels for which the runtime is unavailable, it is too old or the user's
 GPU is not supported, and order the remaining variants by the runtime
-version.  The CPU-only version is published as a null variant that is
+version. The CPU-only version is published as a null variant that is
 always supported.
 
 If a GPU runtime is available and supported, the installer automatically
@@ -950,7 +950,7 @@ installed CPU, mapping them onto the appropriate x86-64 architecture
 level and a set of extended instruction sets. Variant wheels indicate
 which level and/or instruction sets are required. The installer filters
 out variants that do not meet the requirements and select the best
-optimized variant.  A non-variant wheel can be used to represent the
+optimized variant. A non-variant wheel can be used to represent the
 architecture baseline, if supported.
 
 Implementation using wheel variants makes it possible to provide
@@ -967,7 +967,7 @@ BLAS / LAPACK variants
 Packages such as NumPy_ and SciPy_ can be built using different BLAS /
 LAPACK libraries. Users may wish to choose a specific library for
 improved performance on a particular hardware, or based on license
-considerations.  Furthermore, different libraries may use different
+considerations. Furthermore, different libraries may use different
 OpenMP implementations, whereas using a consistent implementation across
 the stack can avoid degrading performance through spawning too many
 threads.
@@ -1137,7 +1137,7 @@ Install-time Provider
 
 Ahead-of-Time Provider
     A provider that features a static list of supported properties which
-    is then embedded in the wheel metadata.  Such a list can either be
+    is then embedded in the wheel metadata. Such a list can either be
     embedded in ``pyproject.toml`` or provided by a plugin queried at
     build time.
 
@@ -1149,12 +1149,12 @@ Wheel variants introduce a more fine-grained specification of built
 wheel characteristics beyond what existing wheel tags provide.
 Individual wheels are characterized by sets of `variant properties`_
 that are organized into a hierarchical structure of namespaces, features
-and feature values.  When evaluating wheels to install, the installer
+and feature values. When evaluating wheels to install, the installer
 must determine whether variant properties are compatible with the
 system, and perform `variant ordering`_ based on the priority of the
 compatible variant properties. This is done in addition to determining
 the compatibility and ordering through tags. The ordering by variant
-properties takes precedence over ordering by tags.  Null variants
+properties takes precedence over ordering by tags. Null variants
 (variants with no variant properties) are preferred over non-variant
 wheels with the same tags.
 
@@ -1423,7 +1423,7 @@ A provider information dictionary may contain the following keys:
   install the provider plugin. If the dependency specifiers include
   environment markers, these are evaluated against the environment where
   the plugin is being installed and the requirements for which the
-  markers evaluate to false are filtered out.  In that case, at least
+  markers evaluate to false are filtered out. In that case, at least
   one dependency must remain present in every possible environment.
   Additionally, if ``plugin-api`` is not specified, the first dependency
   present after filtering must always evaluate to the same API endpoint.
@@ -2211,7 +2211,7 @@ Build backends
 As a build backend can't determine whether the frontend supports variant
 wheels or not, :pep:`517` and :pep:`660` hooks must build non-variant
 wheels by default. Build backends may provide ways to request variant
-builds.  This specification does not define any specific configuration.
+builds. This specification does not define any specific configuration.
 
 
 Variant environment markers