Switch to plain quotation marks

Signed-off-by: Michał Górny <[email protected]>

Author: mgorny

peps/pep-0817.rst

@@ -117,11 +117,11 @@ significant performance improvement.
         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
+    Compiling `GROMACS <https://www.gromacs.org/>`_ for architectures
     that can exploit the AVX-512 instructions supported by the Intel
     Cascade Lake microarchitecture gives an additional 18% performance
     improvement relative to using AVX2 instructions, with a speedup of
-    about 70% compared to a generic GROMACS installation with only SSE2.”
+    about 70% compared to a generic GROMACS installation with only SSE2.
 
     — `archspec: A library for detecting, labeling, and reasoning about
     microarchitectures <https://tgamblin.github.io/pubs/archspec-canopie-hpc-2020.pdf>`__
@@ -194,7 +194,7 @@ Separate package indexes as variants
 
 Projects such as `PyTorch <https://pytorch.org/get-started/locally/>`__
 and `RAPIDS <https://docs.rapids.ai/install/#selector>`__
-currently distribute packages that approximate “variants” through
+currently distribute packages that approximate "variants" through
 separate package indexes with custom URLs. We will use the
 example of PyTorch, while the problem, the workarounds and the impact for
 users also apply to other packages.
@@ -317,7 +317,7 @@ JAX includes 12 extra selectors to cover all use cases - many of which
 overlap and could be misleading to users if they don’t read the
 documentation in detail.
 
-It should be noted that most of these “extras” are technically mutually
+It should be noted that most of these "extras" are technically mutually
 exclusive, though it is currently impossible to correctly express this
 within the package metadata.
 
@@ -432,7 +432,7 @@ computing clusters with different architectures (CPU, Hardware
 accelerators, ASICS, etc.). The current system requires
 environment-specific installation procedures, making reproducible
 deployment difficult. This situation also contributes to making
-“scientific papers” difficult to reproduce. Application authors focused
+"scientific papers" difficult to reproduce. Application authors focused
 on improving that are hindered by the packaging hurdles too:
 
     We've been developing a package manager for Spyder, a Python IDE for
@@ -603,7 +603,7 @@ resolve dependencies like:
     conda install pytorch mkl
 
 **Mutex Metapackages**: Python metadata and conda metadata do not have
-good ways to express ideas like “this package conflicts with that one.”
+good ways to express ideas like "this package conflicts with that one."
 The main mechanism for enforcement is sharing a common package name -
 only one package with a given name can exist at one time. Mutex
 metapackages are sets of packages with the same name, but different
@@ -1071,7 +1071,7 @@ Wheel variant glossary
 ----------------------
 
 This section focuses specifically on the vocabulary used by the proposed
-“Wheel Variant” standard:
+"Wheel Variant" standard:
 
 Variant Wheels
     Wheels that share the same distribution name, version, build number,
@@ -1189,9 +1189,9 @@ The Wheel Variant PEP introduces four key components:
 2. `Variant metadata`_ format: Standardized metadata describing variant
    properties and provider requirements.
 
-   a. Metadata specification at “project level” inside
+   a. Metadata specification at "project level" inside
       ``pyproject.toml``
-   b. Metadata specification of “built packages” inside two JSON files:
+   b. Metadata specification of "built packages" inside two JSON files:
 
       i. ``*.dist-info/variant.json``: Individual wheel variant
          metadata.
@@ -1274,7 +1274,7 @@ The feature value must consist only of ``0-9``, ``a-z``, ``_`` and ``.``
 ASCII Characters (``^[a-z0-9_.]+$``). It must correspond to a valid
 value defined by the respective variant provider for the feature.
 
-If a feature is marked as “multi-value” by the provider plugin, a single
+If a feature is marked as "multi-value" by the provider plugin, a single
 variant wheel may define multiple properties sharing the same namespace
 and feature name. Otherwise, only a single value can correspond to a
 single pair of namespace and feature name within a variant wheel.
@@ -1928,7 +1928,7 @@ methods. The specifics are provided in the subsequent sections.
 API endpoint
 ''''''''''''
 
-The location of the plugin code is called an “API endpoint”, and it is
+The location of the plugin code is called an "API endpoint", and it is
 expressed using the object reference notation following the
 :doc:`packaging:specifications/entry-points`:
 
@@ -1994,7 +1994,7 @@ significant. It is defined using the following protocol:
             """List of values, possibly ordered from most preferred to least"""
             raise NotImplementedError
 
-A “variant feature config” must provide the following properties or attributes:
+A "variant feature config" must provide the following properties or attributes:
 
 - ``name: str`` specifying the feature name.
 
@@ -2061,14 +2061,14 @@ The plugin interface must define the following attributes:
 The plugin interface must provide the following functions:
 
 - ``get_all_config() -> list[VariantFeatureConfigType]`` that returns a
-  list of “variant feature configs” describing all valid variant
+  list of "variant feature configs" describing all valid variant
   features within the plugin’s namespace, along with all their permitted
   values. The ordering of the lists is insignificant here. A particular
   plugin version must always return the same value (modulo ordering),
   irrespective of any runtime conditions.
 
 - ``get_supported_configs() -> list[VariantFeatureConfigType]`` that
-  returns a list of “variant feature configs” describing the variant
+  returns a list of "variant feature configs" describing the variant
   features within the plugin’s namespace that are compatible with this
   particular system, along with their values that are supported. The
   variant feature and value lists must be ordered from the most
@@ -2445,7 +2445,7 @@ Resolving variants to separate packages
 
 An alternative proposal was to publish the variants of the package as
 separate projects on the index, along with the main package serving as a
-“resolver” directing to other variants via its metadata. For example, a
+"resolver" directing to other variants via its metadata. For example, a
 ``torch`` package could indicate the conditions for using ``torch-cpu``,
 ``torch-cu129``, etc. subpackages.
 
@@ -2466,7 +2466,7 @@ maintainers can upload them.
 
 Furthermore, it requires significant changes to the dependency resolver
 and package metadata formats. In particular, the dependency resolver
-would need to query all “resolver” packages before performing
+would need to query all "resolver" packages before performing
 resolution. It is unclear how to account for such variants while
 performing universal resolution. The one-to-one mapping between
 dependencies and installed packages would be lost, as a ``torch``