PEP 621, 635, 637, 639, 642, 644, 645, 647, 650: Fix single backticks (#1797)

Author: hugovk

pep-0621.rst

@@ -104,7 +104,7 @@ then tools MUST raise an error to notify the user about their mistake.
 
 Data specified using this PEP is considered canonical. Tools CANNOT
 remove, add or change data that has been statically specified. Only
-when a field is marked as `dynamic` may a tool provide a "new" value.
+when a field is marked as ``dynamic`` may a tool provide a "new" value.
 
 
 Details

pep-0635.rst

@@ -939,7 +939,7 @@ overall pattern fails, which is not feasible.
 
 To identify sequences we cannot rely on ``len()`` and subscripting and
 slicing alone, because sequences share these protocols with mappings
-(e.g. `dict`) in this regard.  It would be surprising if a sequence
+(e.g. ``dict``) in this regard.  It would be surprising if a sequence
 pattern also matched a dictionaries or other objects implementing
 the mapping protocol (i.e. ``__getitem__``).  The interpreter therefore
 performs an instance check to ensure that the subject in question really
@@ -1141,7 +1141,7 @@ organised structured data in 'tagged tuples' rather than ``struct`` as in
 instance, be a tuple with two elements for the left and right branches,
 respectively, and a ``Node`` tag, written as ``Node(left, right)``.  In
 Python we would probably put the tag inside the tuple as
-``('Node', left, right)`` or define a data class `Node` to achieve the
+``('Node', left, right)`` or define a data class ``Node`` to achieve the
 same effect.
 
 Using modern syntax, a depth-first tree traversal would then be written as
@@ -1216,7 +1216,7 @@ indicator if it is not possible.
 
 In Python, we simply use ``isinstance()`` together with the ``__match_args__``
 field of a class to check whether an object has the correct structure and
-then transform some of its attributes into a tuple.  For the `Node` example
+then transform some of its attributes into a tuple.  For the ``Node`` example
 above, for instance, we would have ``__match_args__ = ('left', 'right')`` to
 indicate that these two attributes should be extracted to form the tuple.
 That is, ``case Node(x, y)`` would first check whether a given object is an
@@ -1229,7 +1229,7 @@ specific attributes.  Instead of ``Node(x, y)`` you could also write
 ``object(left=x, right=y)``, effectively eliminating the ``isinstance()``
 check and thus supporting any object with ``left`` and ``right`` attributes.
 Or you would combine these ideas to write ``Node(right=y)`` so as to require
-an instance of ``Node`` but only extract the value of the `right` attribute.
+an instance of ``Node`` but only extract the value of the ``right`` attribute.
 
 
 Backwards Compatibility

pep-0637.rst

@@ -856,7 +856,7 @@ Allowing for empty index notation obj[]
 The current proposal prevents ``obj[]`` from being valid notation. However
 a commenter stated
 
-    We have ``Tuple[int, int]`` as a tuple of two integers. And we have `Tuple[int]`
+    We have ``Tuple[int, int]`` as a tuple of two integers. And we have ``Tuple[int]``
     as a tuple of one integer. And occasionally we need to spell a tuple of *no*
     values, since that's the type of ``()``. But we currently are forced to write
     that as ``Tuple[()]``. If we allowed ``Tuple[]`` that odd edge case would be

pep-0639.rst

@@ -392,7 +392,7 @@ gently teach users how to provide correct license expressions over time.
 Tools may also help with the conversion and suggest a license expression in some
 cases:
 
-1. The section `Mapping Legacy Classifiers to New License expressions` provides
+1. The section `Mapping Legacy Classifiers to New License expressions`_ provides
    tool authors with guidelines on how to suggest a license expression produced
    from legacy classifiers.
 
@@ -444,8 +444,8 @@ A mapping would be needed as you cannot guarantee that all expressions (e.g.
 GPL with an exception may be in a single file) or all the license keys have a
 single license file and that any expression does not have more than one. (e.g.
 an Apache license ``LICENSE`` and its ``NOTICE`` file for instance are two
-distinct files). Yet in most cases, there is a simpler `one license`, `one or
-more license files`. In the rarer and more complex cases where there are many
+distinct files). Yet in most cases, there is a simpler "one license", "one or
+more license files". In the rarer and more complex cases where there are many
 licenses involved you can still use the proposed conventions at the cost of a
 slight loss of clarity by not specifying which text file is for which license
 identifier, but you are not forcing the more complex data model (e.g. a mapping)
@@ -601,7 +601,7 @@ In Python code files
 (Note: Documenting licenses in source code is not in the scope of this PEP)
 
 Beside using comments and/or ``SPDX-License-Identifier`` conventions, the license
-is sometimes documented in Python code files using `dunder` variables typically
+is sometimes documented in Python code files using "dunder" variables typically
 named after one of the lower cased Core Metadata fields such as ``__license__``
 [#pycode]_.
 
@@ -613,7 +613,7 @@ the ``help()`` DATA section for a module.
 In some other Python packaging tools
 ------------------------------------
 
-- `Conda package manifest` [#conda]_ has support for ``license`` and ``license_file``
+- Conda package manifest [#conda]_ has support for ``license`` and ``license_file``
   fields as well as a ``license_family`` license grouping field.
 
 - ``flit`` [#flit]_ recommends to use classifiers instead of License (as per the

pep-0642.rst

@@ -191,7 +191,7 @@ then we don't have any real way to revisit those decisions in a future release.
 Specification
 =============
 
-This PEP retains the overall `match`/`case` statement structure and semantics
+This PEP retains the overall ``match``/``case`` statement structure and semantics
 from PEP 634, but proposes multiple changes that mean that user intent is
 explicitly specified in the concrete syntax rather than needing to be inferred
 from the pattern matching context.
@@ -2007,7 +2007,7 @@ The following new nodes are added to the AST by this PEP::
 Appendix C: Summary of changes relative to PEP 634
 ==================================================
 
-The overall `match`/`case` statement syntax and the guard expression syntax
+The overall ``match``/``case`` statement syntax and the guard expression syntax
 remain the same as they are in PEP 634.
 
 Relative to PEP 634 this PEP makes the following key changes:

pep-0644.rst

@@ -22,12 +22,12 @@ incompatible forks, and other TLS libraries are dropped.
 Motivation
 ==========
 
-Python makes use of OpenSSL in `hashlib`, `hmac`, and `ssl` modules. OpenSSL
+Python makes use of OpenSSL in ``hashlib``, ``hmac``, and ``ssl`` modules. OpenSSL
 provides fast implementations of cryptographic primitives and a full TLS
-stack including handling of X.509 certificates. The `ssl` module is used by
-standard library modules like `urllib` and 3rd party modules like `urllib3`
-to implement secure variants of internet protocols. `pip` uses the `ssl`
-module to securely download packages from PyPI. Any bug in the ssl module's
+stack including handling of X.509 certificates. The ``ssl`` module is used by
+standard library modules like ``urllib`` and 3rd party modules like ``urllib3``
+to implement secure variants of internet protocols. ``pip`` uses the ``ssl``
+module to securely download packages from PyPI. Any bug in the ``ssl`` module's
 bindings to OpenSSL can lead to a severe security issue.
 
 Over time OpenSSL's public API has evolved and changed. Version 1.0.2
@@ -164,7 +164,7 @@ created: 2014-04 (forked from OpenSSL 1.0.1g)
 Some distributions like FreeBSD, Gentoo, and OPNsense also feature LibreSSL
 instead of OpenSSL as non-standard TLS libraries.
 
-OpenBSD ports has a port `security/openssl/1.1` which is documented as
+OpenBSD ports has a port ``security/openssl/1.1`` which is documented as
 "[...] is present to provide support for applications which cannot be made
 compatible with LibReSSL" [7]_. The package could be used by OpenBSD to
 provide a working ssl module.
@@ -203,9 +203,9 @@ SHA-3
 
 Since 1.1.0, OpenSSL ships with SHA-3 and SHAKE implementations.
 Python's builtin SHA-3 support is based on the reference implementation. The
-internal `_sha3` code is fairly large and the resulting shared library close
+internal ``_sha3`` code is fairly large and the resulting shared library close
 to 0.5 MB. Python could drop the builtin implementation and rely on OpenSSL's
-`libcrypto` instead.
+``libcrypto`` instead.
 
 So far LibreSSL upstream development has refused to add SHA-3 support. [2]_
 
@@ -217,7 +217,7 @@ OpenSSL downstream patches and options
 --------------------------------------
 
 OpenSSL features more than 70 configure and build time options in the form
-of  `OPENSSL_NO_*` macros. Around 60 options affect the presence of features
+of  ``OPENSSL_NO_*`` macros. Around 60 options affect the presence of features
 like cryptographic algorithms and TLS versions. Some distributions apply
 patches to alter settings. Furthermore, default values for settings like
 security level, ciphers, TLS version range, and signature algorithms can
@@ -227,8 +227,8 @@ The Python core team lacks resources to test all possible combinations.
 This PEP proposes that Python only supports OpenSSL builds that have
 standard features enabled. Vendors shall disable deprecated or insecure
 algorithms and TLS versions with build time options like
-`OPENSSL_NO_TLS1_1_METHOD` or OpenSSL config options like
-`MinProtocol = TLSv1.2`.
+``OPENSSL_NO_TLS1_1_METHOD`` or OpenSSL config options like
+``MinProtocol = TLSv1.2``.
 
 Python assumes that OpenSSL is built with
 
@@ -260,7 +260,7 @@ latest release LibreSSL 3.3.2 is missing features and behaves differently
 in some cases. Mentionable missing or incompatible features include
 
 - SHA-3, SHAKE, BLAKE2
-- `SSL_CERT_*` environment variables
+- ``SSL_CERT_*`` environment variables
 - security level APIs
 - session handling APIs
 - key logging API

pep-0645.rst

@@ -59,8 +59,8 @@ The widespread adoption and popularity of these languages means that Python deve
     // Optional in C#
     string? example;
 
-Adding this syntax would also follow the often used pattern of using builtin types as annotations. For example, `list`, `dict` and `None`. This would allow more annotations to be
-added to Python code without importing from `typing`.
+Adding this syntax would also follow the often used pattern of using builtin types as annotations. For example, ``list``, ``dict`` and ``None``. This would allow more annotations to be
+added to Python code without importing from ``typing``.
 
 
 Specification
@@ -107,7 +107,7 @@ Since the new Union syntax specified in PEP 604 is supported in ``isinstance`` a
     isinstance(1, int?) # true
     issubclass(Child, Super?) # true
 
-A new dunder method will need to be implemented to allow the `?` operator to be overloaded for other functionality.
+A new dunder method will need to be implemented to allow the ``?`` operator to be overloaded for other functionality.
 
 
 Backwards Compatibility

pep-0647.rst

@@ -205,8 +205,8 @@ narrowed within the conditional code block.
 
 Some built-in type guards provide narrowing for both positive and negative
 tests (in both the ``if`` and ``else`` clauses). For example, consider the
-type guard for an expression of the form `x is None`. If `x` has a type that
-is a union of None and some other type, it will be narrowed to `None` in the
+type guard for an expression of the form ``x is None``. If ``x`` has a type that
+is a union of None and some other type, it will be narrowed to ``None`` in the
 positive case and the other type in the negative case. User-defined type
 guards apply narrowing only in the positive case (the ``if`` clause). The type
 is not narrowed in the negative case.

pep-0650.rst

@@ -597,8 +597,8 @@ though, it was considered an orthogonal idea.
 Open Issues
 ===========
 
-Should the `dependency_group` argument take an iterable?
---------------------------------------------------------
+Should the ``dependency_group`` argument take an iterable?
+----------------------------------------------------------
 
 This would allow for specifying non-overlapping dependency groups in
 a single call, e.g. "docs" and "test" groups which have independent