fix lint errors

Author: iritkatriel

peps/pep-0765.rst

@@ -160,41 +160,41 @@ Rejected Ideas
 Emit `SyntaxError` in CPython
 -----------------------------
 
-:pep:`601` proposed that CPython would emit `SyntaxWarning` for a couple of
-releases and `SyntaxError` afterwards. We are leaving it open whether, and
-when, this will become a `SyntaxError` in CPython, because we believe that a
-`SyntaxWarning` would give most of the benefit with less risk.
+:pep:`601` proposed that CPython would emit ``SyntaxWarning`` for a couple of
+releases and ``SyntaxError`` afterwards. We are leaving it open whether, and
+when, this will become a ``SyntaxError`` in CPython, because we believe that a
+``SyntaxWarning`` would provide most of the benefit with less risk.
 
 Change Semantics
 ----------------
 
 It `was suggested <https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348/32>`__
 to change the semantics of control flow instruction in finally such that an
-in-flight exception takes precedence over them.  In other words, a `return`,
-`break` or `continue` would be permitted, and would exit the `finally` block,
-but the exception would still be raised.
+in-flight exception takes precedence over them.  In other words, a ``return``,
+``break`` or ``continue`` would be permitted, and would exit the ``finally``
+block, but the exception would still be raised.
 
 This was rejected for two reasons. First, it would change the semantics of
-working code in a way that can be hard to debug: a `finally` that was written
+working code in a way that can be hard to debug: a ``finally`` that was written
 with the intention of swallowing all exceptions (correctly using the documented
 semantics) would now allow the exception to propagate on. This may happen only
 in rare edge cases at runtime, and is not guaranteed to be detected in testing.
 Even if the code is wrong, and has an exception swallowing bug, it could be
 hard for users to understand why a program started raising exceptions in 3.14,
 while it did not in 3.13.
-In contrast, a `SyntaxError` is likely to be seen during testing, it would
+In contrast, a ``SyntaxError`` is likely to be seen during testing, it would
 point to the precise location of the problem in the code, and it would not
 prevent the program from running.
 
 The second objection was about the proposed semantics. The motivation for
 allowing control flow statements is not that this would be useful, but rather
 the desire for orthogonality of features (which, as we mentioned in the
-introduction, is already violated in the case of `except*` clauses). However,
-the proposed semantics are complicated because they suggest that `return`,
-`break` and `continue` behave as they normally when finally is called without
-an in-flight exception, but turn into something like a bare `raise` when there
-is one. It is hard to claim that the features are orthogonal if the presence
-of one changes the semantics of the other.
+introduction, is already violated in the case of ``except*`` clauses). However,
+the proposed semantics are complicated because they suggest that ``return``,
+``break`` and ``continue`` behave as they normally when finally is called
+without an in-flight exception, but turn into something like a bare ``raise``
+when there is one. It is hard to claim that the features are orthogonal if
+the presence of one changes the semantics of the other.
 
 Copyright
 =========