PEP 572: Fix formatting

pep-0572.rst

@@ -33,8 +33,8 @@ Syntax and semantics
 
 In any context where arbitrary Python expressions can be used, a named
 expression can appear. This must be parenthesized for clarity, and is of
-the form `(expr as NAME)` where `expr` is any valid Python expression,
-and `NAME` is a simple name.
+the form ``(expr as NAME)`` where ``expr`` is any valid Python expression,
+and ``NAME`` is a simple name.
 
 The value of such a named expression is the same as the incorporated
 expression, with the additional side-effect that NAME is bound to that
@@ -73,21 +73,21 @@ These list comprehensions are all approximately equivalent::
     # Using a statement-local name
     stuff = [[(f(x) as y), y] for x in range(5)]
 
-If calling `f(x)` is expensive or has side effects, the clean operation of
+If calling ``f(x)`` is expensive or has side effects, the clean operation of
 the list comprehension gets muddled. Using a short-duration name binding
-retains the simplicity; while the extra `for` loop does achieve this, it
+retains the simplicity; while the extra ``for`` loop does achieve this, it
 does so at the cost of dividing the expression visually, putting the named
 part at the end of the comprehension instead of the beginning.
 
 Statement-local name bindings can be used in any context, but should be
-avoided where regular assignment can be used, just as `lambda` should be
-avoided when `def` is an option.
+avoided where regular assignment can be used, just as ``lambda`` should be
+avoided when ``def`` is an option.
 
 
 Open questions
 ==============
 
-1. What happens if the name has already been used? `(x, (1 as x), x)`
+1. What happens if the name has already been used? ``(x, (1 as x), x)``
    Currently, prior usage functions as if the named expression did not
    exist (following the usual lookup rules); the new name binding will
    shadow the other name from the point where it is evaluated until the
@@ -104,17 +104,17 @@ Open questions
    shadow any other names from the same function), or should they simply
    not appear?
 
-4. Syntactic confusion in `except` statements.  While technically
+4. Syntactic confusion in ``except`` statements.  While technically
    unambiguous, it is potentially confusing to humans.  In Python 3.7,
-   parenthesizing `except (Exception as e):` is illegal, and there is no
+   parenthesizing ``except (Exception as e):`` is illegal, and there is no
    reason to capture the exception type (as opposed to the exception
    instance, as is done by the regular syntax).  Should this be made
    outright illegal, to prevent confusion?  Can it be left to linters?
 
-5. Similar confusion in `with` statements, with the difference that there
+5. Similar confusion in ``with`` statements, with the difference that there
    is good reason to capture the result of an expression, and it is also
-   very common for `__enter__` methods to return `self`.  In many cases,
-   `with expr as name:` will do the same thing as `with (expr as name):`,
+   very common for ``__enter__`` methods to return ``self``.  In many cases,
+   ``with expr as name:`` will do the same thing as ``with (expr as name):``,
    adding to the confusion.