From ede96d590d63bad5e4e669c10c0a6af64a8684ff Mon Sep 17 00:00:00 2001 From: Irit Katriel Date: Tue, 19 Nov 2024 19:14:06 +0000 Subject: [PATCH] fix lint errors --- peps/pep-0765.rst | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst index 4121cb74d98..2bb5e25ec86 100644 --- a/peps/pep-0765.rst +++ b/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 `__ 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 =========