diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst index 7fd2260a759..b73e807a41c 100644 --- a/peps/pep-0765.rst +++ b/peps/pep-0765.rst @@ -169,7 +169,7 @@ Change Semantics ---------------- It `was suggested `__ -to change the semantics of control flow instruction in finally such that an +to change the semantics of control flow instructions 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. @@ -182,7 +182,7 @@ 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 ``SyntaxWarning`` 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. @@ -191,7 +191,7 @@ 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 +``break`` and ``continue`` behave as they normally when ``finally`` is used 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.