Remove additional backticks from inline code (#2033)

pep-0211.txt

@@ -120,7 +120,7 @@ Discussion
     (1, 2) @ (3, 4) @ (5, 6)
 
    would have to return ``(1, 3, 5) ... (2, 4, 6)``, and *not*
-   ``((1, 3), 5) ... ((2, 4), 6)```.  This should not require special
+   ``((1, 3), 5) ... ((2, 4), 6)``.  This should not require special
    support from the parser, as the outer iterator created by the
    first ``@`` could easily be taught how to combine itself with
    ordinary iterators.

pep-0543.rst

@@ -936,16 +936,16 @@ unless they have specific reasons to do so.
 NSS has both process global and per-connection settings for cipher suites. It
 does not have a concept of SSLContext like OpenSSL. A SSLContext-like behavior
 can be easily emulated. Specifically, ciphers can be enabled or disabled
-globally with ```SSL_CipherPrefSetDefault(PRInt32 cipher, PRBool enabled)```,
-and ```SSL_CipherPrefSet(PRFileDesc *fd, PRInt32 cipher, PRBool enabled)```
-for a connection. The cipher ```PRInt32``` number is a signed 32bit integer
-that directly corresponds to an registered IANA id, e.g. ```0x1301```
-is ```TLS_AES_128_GCM_SHA256```. Contrary to OpenSSL, the preference order
+globally with ``SSL_CipherPrefSetDefault(PRInt32 cipher, PRBool enabled)``,
+and ``SSL_CipherPrefSet(PRFileDesc *fd, PRInt32 cipher, PRBool enabled)``
+for a connection. The cipher ``PRInt32`` number is a signed 32bit integer
+that directly corresponds to an registered IANA id, e.g. ``0x1301``
+is ``TLS_AES_128_GCM_SHA256``. Contrary to OpenSSL, the preference order
 of ciphers is fixed and cannot be modified at runtime.
 
 Like SecureTransport, NSS has no API for aggregated entries. Some consumers
 of NSS have implemented custom mappings from OpenSSL cipher names and rules
-to NSS ciphers, e.g. ```mod_nss```.
+to NSS ciphers, e.g. ``mod_nss``.
 
 
 Proposed Interface

pep-0642.rst

@@ -889,7 +889,7 @@ converted to an instance attributes constraint as follows:
 - if only the double star attribute constraints subpattern is present, matching
   proceeds as if for the equivalent instance attributes constraint.
 - if there are more positional subpatterns than the length of
-  ``__match_args__``` (as obtained using ``len()``), ``TypeError`` is raised.
+  ``__match_args__`` (as obtained using ``len()``), ``TypeError`` is raised.
 - Otherwise, positional pattern ``i`` is converted to an attribute pattern
   using ``__match_args__[i]`` as the attribute name.
 - if any element in ``__match_args__`` is not a string, ``TypeError`` is raised.
@@ -2058,7 +2058,7 @@ Relative to PEP 634 this PEP makes the following key changes:
 * class patterns treat any class that sets ``__match_args__`` to ``None`` as
   accepting a single positional pattern that is matched against the entire
   object (avoiding the special casing required in PEP 634)
-* class patterns raise ``TypeError` when used with an object that does not
+* class patterns raise ``TypeError`` when used with an object that does not
   define ``__match_args__``
 * dedicated syntax for ducktyping is added, such that ``case cls{...}:`` is
   roughly equivalent to ``case cls(**{...}):``, but skips the check for the

pep-0647.rst

@@ -314,10 +314,10 @@ Conditionally Applying TypeGuard Type
 It was suggested that the expression passed as the first argument to a type
 guard function should retain its existing type if the type of the expression was
 a proper subtype of the type specified in the TypeGuard return type.
-For example, if the type guard function is ```def f(value: object) -> 
-TypeGuard[float]``` and the expression passed to this function is of type
-```int```, it would retain the ```int``` type rather than take on the
-```float``` type indicated by the TypeGuard return type. This proposal was
+For example, if the type guard function is ``def f(value: object) ->
+TypeGuard[float]`` and the expression passed to this function is of type
+``int``, it would retain the ``int`` type rather than take on the
+``float`` type indicated by the TypeGuard return type. This proposal was
 rejected because it added complexity, inconsistency, and opened up additional
 questions about the proper behavior if the type of the expression was of
 composite types like unions or type variables with multiple constraints. It was

pep-0660.rst

@@ -215,7 +215,7 @@ Frontends must execute ``get_requires_for_build_editable`` hooks in
 an environment which contains the bootstrap requirements specified in the
 ``pyproject.toml`` file.
 
-Frontends must execute the ````prepare_metadata_for_build_editable`` and
+Frontends must execute the ``prepare_metadata_for_build_editable`` and
 ``build_editable`` hooks in an environment which contains the bootstrap
 requirements from ``pyproject.toml`` and those specified by the
 ``get_requires_for_build_editable`` hook.

pep-3100.txt

@@ -120,7 +120,7 @@ To be removed:
 * String exceptions: use instances of an Exception class [2]_ [done]
 * ``raise Exception, "message"``: use ``raise Exception("message")`` [12]_
   [done]
-* ```x```: use ``repr(x)`` [2]_ [done]
+* ``x``: use ``repr(x)`` [2]_ [done]
 * The ``<>`` operator: use ``!=`` instead [3]_ [done]
 * The __mod__ and __divmod__ special methods on float. [they should stay] [21]_
 * Drop unbound methods [7]_ [25]_ [done]