fix markup for rogue grave accents

AA-Turner · AA-Turner · commit 99bef6b72ccb · 2022-01-21T10:56:46.000Z
diff --git a/pep-0101.txt b/pep-0101.txt
@@ -548,52 +548,52 @@ the main repo.
   following feature release.  When finished, the ``main``
   branch will now build Python ``X.Y+1``.
 
-    - First, set main up to be the next release, i.e.X.Y+1.a0::
+  - First, set main up to be the next release, i.e.X.Y+1.a0::
 
-        $ git checkout main
-        $ .../release-tools/release.py --bump 3.9.0a0
+      $ git checkout main
+      $ .../release-tools/release.py --bump 3.9.0a0
 
-    - Edit all version references in README.rst
+  - Edit all version references in README.rst
 
-    - Move any historical "what's new" entries from ``Misc/NEWS`` to
-      ``Misc/HISTORY``.
+  - Move any historical "what's new" entries from ``Misc/NEWS`` to
+    ``Misc/HISTORY``.
 
-    - Edit ``Doc/tutorial/interpreter.rst`` (2 references to '[Pp]ython3x',
-      one to 'Python 3.x', also make the date in the banner consistent).
+  - Edit ``Doc/tutorial/interpreter.rst`` (2 references to '[Pp]ython3x',
+    one to 'Python 3.x', also make the date in the banner consistent).
 
-    - Edit ``Doc/tutorial/stdlib.rst`` and ``Doc/tutorial/stdlib2.rst``, which
-      have each one reference to '[Pp]ython3x'.
+  - Edit ``Doc/tutorial/stdlib.rst`` and ``Doc/tutorial/stdlib2.rst``, which
+    have each one reference to '[Pp]ython3x'.
 
-    - Add a new ``whatsnew/3.x.rst`` file (with the comment near the top
-      and the toplevel sections copied from the previous file) and
-      add it to the toctree in ``whatsnew/index.rst``.  But beware that
-      the initial ``whatsnew/3.x.rst`` checkin from previous releases
-      may be incorrect due to the initial midstream change to ``blurb``
-      that propagates from release to release!  Help break the cycle: if
-      necessary make the following change::
+  - Add a new ``whatsnew/3.x.rst`` file (with the comment near the top
+    and the toplevel sections copied from the previous file) and
+    add it to the toctree in ``whatsnew/index.rst``.  But beware that
+    the initial ``whatsnew/3.x.rst`` checkin from previous releases
+    may be incorrect due to the initial midstream change to ``blurb``
+    that propagates from release to release!  Help break the cycle: if
+    necessary make the following change::
 
-          - For full details, see the :source:`Misc/NEWS` file.
-          + For full details, see the :ref:`changelog <changelog>`.
+        - For full details, see the :source:`Misc/NEWS` file.
+        + For full details, see the :ref:`changelog <changelog>`.
 
-    - Update the version number in ``configure.ac`` and re-run ``autoconf``.
+  - Update the version number in ``configure.ac`` and re-run ``autoconf``.
 
-    - Make sure the ``SOURCE_URI`` in ``Doc/tools/extensions/pyspecific.py``
-      points to ``main``.
+  - Make sure the ``SOURCE_URI`` in ``Doc/tools/extensions/pyspecific.py``
+    points to ``main``.
 
-    - Update the version numbers for the Windows builds in PC/ and
-      PCbuild/, which have references to python38.
-      NOTE, check with Steve Dower about this step, it is probably obsolete.::
+  - Update the version numbers for the Windows builds in PC/ and
+    PCbuild/, which have references to python38.
+    NOTE, check with Steve Dower about this step, it is probably obsolete.::
 
-          $ find PC/ PCbuild/ -type f | xargs sed -i 's/python38/python39/g'
-          $ git mv -f PC/os2emx/python38.def PC/os2emx/python39.def
-          $ git mv -f PC/python38stub.def PC/python39stub.def
-          $ git mv -f PC/python38gen.py PC/python39gen.py
+        $ find PC/ PCbuild/ -type f | xargs sed -i 's/python38/python39/g'
+        $ git mv -f PC/os2emx/python38.def PC/os2emx/python39.def
+        $ git mv -f PC/python38stub.def PC/python39stub.def
+        $ git mv -f PC/python38gen.py PC/python39gen.py
 
-    - Commit these changes to the main branch::
+  - Commit these changes to the main branch::
 
-          $ git status
-          $ git add ...
-          $ git commit -m 'Bump to 3.9.0a0'
+        $ git status
+        $ git add ...
+        $ git commit -m 'Bump to 3.9.0a0'
 
 - Do another ``git status`` in this directory.
 
diff --git a/pep-0103.txt b/pep-0103.txt
@@ -137,7 +137,7 @@ you have done something like that::
     $ git branch v1 origin/v1
 
 The first command clones remote repository into local directory
-`python``, creates a new local branch master, sets
+``python``, creates a new local branch master, sets
 remotes/origin/master as its upstream remote-tracking branch and
 checks it out into the working directory.
 
diff --git a/pep-0261.txt b/pep-0261.txt
@@ -201,7 +201,7 @@ There is a new configure option:
 =====================  ============================================
 --enable-unicode=ucs2  configures a narrow ``Py_UNICODE``, and uses
                        wchar_t if it fits
---enable-unicode=ucs4  configures a wide `Py_UNICODE``, and uses
+--enable-unicode=ucs4  configures a wide ``Py_UNICODE``, and uses
                        wchar_t if it fits
 --enable-unicode       same as "=ucs2"
 --disable-unicode      entirely remove the Unicode functionality.
diff --git a/pep-0339.txt b/pep-0339.txt
@@ -83,7 +83,7 @@ To tie all of this example, consider the rule for 'while'::
 The node representing this will have ``TYPE(node) == while_stmt`` and
 the number of children can be 4 or 7 depending on if there is an 'else'
 statement.  To access what should be the first ':' and require it be an
-actual ':' token, `(REQ(CHILD(node, 2), COLON)``.
+actual ':' token, ``(REQ(CHILD(node, 2), COLON)``.
 
 
 Abstract Syntax Trees (AST)
diff --git a/pep-0444.txt b/pep-0444.txt
@@ -503,7 +503,7 @@ string.  Each value is a bytes instance.
 
 ``SERVER_NAME``, ``SERVER_PORT``
   When combined with ``SCRIPT_NAME`` and ``PATH_INFO`` (or their raw
-  equivalents)`, these variables can be used to complete the URL.
+  equivalents), these variables can be used to complete the URL.
   Note, however, that ``HTTP_HOST``, if present, should be used in
   preference to ``SERVER_NAME`` for reconstructing the request URL.
   See the `URL Reconstruction`_ section below for more detail.
diff --git a/pep-0465.txt b/pep-0465.txt
@@ -1134,11 +1134,11 @@ systems work.
 
 **Use a special "facade" type to support syntax like arr.M * arr:**
 This is very similar to the previous proposal, in that the ``.M``
-attribute would basically return the same object as ``arr *dot` would,
+attribute would basically return the same object as ``arr *dot`` would,
 and thus suffers the same objections about 'magicalness'.  This
 approach also has some non-obvious complexities: for example, while
-``arr.M * arr`` must return an array, ``arr.M * arr.M`` and ``arr *
-arr.M`` must return facade objects, or else ``arr.M * arr.M * arr``
+``arr.M * arr`` must return an array, ``arr.M * arr.M`` and
+``arr * arr.M`` must return facade objects, or else ``arr.M * arr.M * arr``
 and ``arr * arr.M * arr`` will not work.  But this means that facade
 objects must be able to recognize both other array objects and other
 facade objects (which creates additional complexity for writing
diff --git a/pep-0467.txt b/pep-0467.txt
@@ -143,7 +143,7 @@ to handle this use-case::
    b'123'
 
 Note that ``bytes.ascii()`` would handle simple ascii-encodable text correctly,
-unlike the `ascii()`` built-in::
+unlike the ``ascii()`` built-in::
 
    >>> ascii("hello").encode('ascii')
    b"'hello'"
diff --git a/pep-0505.rst b/pep-0505.rst
@@ -751,7 +751,7 @@ Going back to one of the motivating examples above, consider the following::
 
     >>> import json
     >>> created = None
-    >>> json.dumps({'created': created?.isoformat()})``
+    >>> json.dumps({'created': created?.isoformat()})
 
 The JSON serializer does not know how to serialize ``NoneQuestion``, nor will
 any other API. This proposal actually requires *lots of specialized logic*
diff --git a/pep-0532.txt b/pep-0532.txt
@@ -660,7 +660,7 @@ raised when discussing PEPs 335, 505 and 531.
 
 One consequence of this approach is that this PEP *on its own* doesn't produce
 much in the way of direct benefits to end users aside from making it possible
-to omit some common ``None if `` prefixes and `` else None`` suffixes from
+to omit some common ``None if`` prefixes and ``else None`` suffixes from
 particular forms of conditional expression.
 
 Instead, what it mainly provides is a common foundation that would allow the
@@ -759,13 +759,13 @@ expression as follows::
     >>> maybe_value = is_not_none(data.get("key"))
     >>> maybe_value if maybe_value else y
 
-If `bool(maybe_value)`` is ``True``, then the expression short-circuits and
+If ``bool(maybe_value)`` is ``True``, then the expression short-circuits and
 the interpreter calls ``type(maybe_value).__else__(maybe_value, maybe_value)``.
 The implementation of ``types.CircuitBreaker.__then__`` detects that the
 instance method has received itself as its argument and returns the wrapped
 value (i.e. ``data.get("key")``) rather than the circuit breaker.
 
-If `bool(maybe_value)`` is ``True``, the interpreter calls
+If ``bool(maybe_value)`` is ``True``, the interpreter calls
 ``type(maybe_value).__else__(maybe_value, y)``. The implementation of
 ``types.CircuitBreaker.__else__`` doesn't see anything that indicates
 short-circuiting has taken place, and hence returns ``y``.
diff --git a/pep-0570.rst b/pep-0570.rst
@@ -655,7 +655,7 @@ passed by position or keyword::
    >>> standard_arg(arg=2)
    2
 
-The second function ``pos_only_arg` is restricted to only use positional
+The second function ``pos_only_arg`` is restricted to only use positional
 parameters as there is a ``/`` in the function definition::
 
    >>> pos_only_arg(1)
diff --git a/pep-0577.rst b/pep-0577.rst
@@ -15,7 +15,7 @@ PEP Withdrawal
 While working on this PEP, I realised that it didn't really address what was
 actually bothering me about :pep:`572`'s proposed scoping rules for previously
 unreferenced assignment targets, and also had some significant undesirable
-consequences (most notably, allowing ``>>=` and ``<<=`` as inline augmented
+consequences (most notably, allowing ``>>=`` and ``<<=`` as inline augmented
 assignment operators that meant something entirely different from the ``>=``
 and ``<=`` comparison operators).
 
@@ -171,7 +171,7 @@ value is a tuple without parentheses).
 
 The difference this introduces relative to :pep:`572` is that where
 ``(n := first, second)`` sets ``n = first`` in :pep:`572`, in this PEP it would set
-``n = (first, second)`, and getting the first meaning would require an extra
+``n = (first, second)``, and getting the first meaning would require an extra
 set of parentheses (``((n := first), second)``).
 
 :pep:`572` quite reasonably notes that this results in ambiguity when assignment
diff --git a/pep-0646.rst b/pep-0646.rst
@@ -910,7 +910,7 @@ passed to ``__getitem__``. For example, if we do ``foo[a, *b, c]``, and
 ``foo.__getitem__`` would receive ``(a, d, e, c)``.
 
 To put it another way, note that ``x[..., *a, ...]`` produces the same result
-as ``x[(..., *a, ...)]``` (with any slices ``i:j`` in ``...`` replaced with
+as ``x[(..., *a, ...)]`` (with any slices ``i:j`` in ``...`` replaced with
 ``slice(i, j)``, with the one edge case that ``x[*a]`` becomes ``x[(*a,)]``).
 
 TypeVarTuple Implementation
diff --git a/pep-0662.rst b/pep-0662.rst
@@ -138,7 +138,7 @@ For reference, a non-editable installation works as follows:
    :pep:`518` environment. Once invoked, the backend returns a wheel.
 
 #. The frontend takes the wheel and feeds it to an **installer**
-   (e.g.,`installer`_) to install the wheel into the target Python interpreter.
+   (e.g., installer_) to install the wheel into the target Python interpreter.
 
 The Mechanism
 =============
diff --git a/pep-0668.rst b/pep-0668.rst
@@ -374,8 +374,8 @@ In more detail, the use cases above are:
    worth calling out explicitly, because anything on the global
    ``sys.path`` is visible.
 
-   Currently, the answer to "Will ``pip` delete externally-installed
-   packages`` is no, because pip has a special case for running in a
+   Currently, the answer to "Will ``pip`` delete externally-installed
+   packages" is no, because pip has a special case for running in a
    virtual environment and attempting to delete packages outside it.
    After this PEP, the answer remains no, but the reasoning becomes
    more general: system site packages will be outside any of the
@@ -1060,7 +1060,7 @@ References
 
 For additional background on these problems and previous attempts to
 solve them, see `Debian bug 771794`_ "pip silently removes/updates
-system provided python packages` from 2014, Fedora's 2018 article
+system provided python packages" from 2014, Fedora's 2018 article
 `Making sudo pip safe`_ about pointing ``sudo pip`` at /usr/local
 (which acknowledges that the changes still do not make ``sudo pip``
 completely safe), pip issues 5605_ ("Disable upgrades to existing
diff --git a/pep-0677.rst b/pep-0677.rst
@@ -518,7 +518,7 @@ We discussed each of these behaviors and believe they are desirable:
   valid in function signature returns, so we need to allow operators
   in the return position for consistency.
 - Given that operators bind more tightly than ``->`` it is correct
-  that a type like ```bool | () -> bool`` must be a syntax error. We
+  that a type like ``bool | () -> bool`` must be a syntax error. We
   should be sure the error message is clear because this may be a
   common mistake.
 - Associating ``->`` to the right, rather than requiring explicit
@@ -908,7 +908,7 @@ of callback protocols::
         named: str,
         *args: float,
         keyword_only: int = ...,
-        **kwargs: str)`
+        **kwargs: str
     ) -> bool: ...
 
     f: CallableType = ...
diff --git a/pep-3099.txt b/pep-3099.txt
@@ -149,8 +149,8 @@ Core language
 * The ``else`` clause in ``while`` and ``for`` loops will not change
   semantics, or be removed.
 
-  Thread: "for/except/else syntax"
-  https://mail.python.org/pipermail/python-ideas/2009-October/006083.html
+   Thread: "for/except/else syntax"
+   https://mail.python.org/pipermail/python-ideas/2009-October/006083.html
 
 
 Builtins

Original file line number	Diff line number	Diff line change
`@@ -655,7 +655,7 @@ passed by position or keyword::`
`655`	`655`	`>>> standard_arg(arg=2)`
`656`	`656`	`2`
`657`	`657`
`658`		-The second function ``pos_only_arg` is restricted to only use positional
	`658`	+The second function ``pos_only_arg`` is restricted to only use positional
`659`	`659`	parameters as there is a ``/`` in the function definition::
`660`	`660`
`661`	`661`	`>>> pos_only_arg(1)`