From c2f3540a974fa27608e5f184d3ec0278637b8c1f Mon Sep 17 00:00:00 2001 From: Irit Katriel Date: Tue, 19 Nov 2024 19:08:46 +0000 Subject: [PATCH 1/8] PEP 765: add rejected ideas section --- peps/pep-0765.rst | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst index f2036b0b1a8..c9418f68bb9 100644 --- a/peps/pep-0765.rst +++ b/peps/pep-0765.rst @@ -154,6 +154,48 @@ that their code needs to change. The `empirical evidence shows that the changes necessary are typically quite straightforward. +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. + +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. + +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 +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 +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 feature (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. + Copyright ========= From bc0cbf52683c21da3c4bb4f99473d1df78abf62e Mon Sep 17 00:00:00 2001 From: Irit Katriel <1055913+iritkatriel@users.noreply.github.com> Date: Tue, 19 Nov 2024 19:10:40 +0000 Subject: [PATCH 2/8] Update peps/pep-0765.rst --- peps/pep-0765.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst index c9418f68bb9..4121cb74d98 100644 --- a/peps/pep-0765.rst +++ b/peps/pep-0765.rst @@ -188,7 +188,7 @@ 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 feature (which, as we mentioned in the +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 From ede96d590d63bad5e4e669c10c0a6af64a8684ff Mon Sep 17 00:00:00 2001 From: Irit Katriel Date: Tue, 19 Nov 2024 19:14:06 +0000 Subject: [PATCH 3/8] 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 ========= From b6710296070d51b2a648bdac18cf2247e3c688e9 Mon Sep 17 00:00:00 2001 From: Irit Katriel Date: Tue, 19 Nov 2024 19:26:01 +0000 Subject: [PATCH 4/8] fix lint error --- peps/pep-0765.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst index 2bb5e25ec86..7fd2260a759 100644 --- a/peps/pep-0765.rst +++ b/peps/pep-0765.rst @@ -157,8 +157,8 @@ straightforward. Rejected Ideas ============== -Emit `SyntaxError` in CPython ------------------------------ +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 From 71db2ddf818cf8b5a199657afebc6c3d54097896 Mon Sep 17 00:00:00 2001 From: Irit Katriel <1055913+iritkatriel@users.noreply.github.com> Date: Tue, 19 Nov 2024 19:36:37 +0000 Subject: [PATCH 5/8] Apply suggestions from code review Co-authored-by: Jelle Zijlstra --- peps/pep-0765.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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. From ba95a0defedec600173abe621a19473c33f3b670 Mon Sep 17 00:00:00 2001 From: Irit Katriel <1055913+iritkatriel@users.noreply.github.com> Date: Tue, 19 Nov 2024 19:37:10 +0000 Subject: [PATCH 6/8] Update peps/pep-0765.rst --- peps/pep-0765.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst index b73e807a41c..239ec6748b7 100644 --- a/peps/pep-0765.rst +++ b/peps/pep-0765.rst @@ -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 used +``break`` and ``continue`` behave as they normally when ``finally`` executes 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. From b28d597c5054da32a9e7dfcba7df491fad5c7cb2 Mon Sep 17 00:00:00 2001 From: Irit Katriel <1055913+iritkatriel@users.noreply.github.com> Date: Wed, 20 Nov 2024 12:18:35 +0000 Subject: [PATCH 7/8] Update peps/pep-0765.rst --- peps/pep-0765.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst index ddcde3c0f51..9881405d312 100644 --- a/peps/pep-0765.rst +++ b/peps/pep-0765.rst @@ -171,7 +171,7 @@ Change Semantics ---------------- It `was suggested `__ -to change the semantics of control flow instructions 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. From bf0612856dc6ad0ab29bd3d8af818f76f80fee16 Mon Sep 17 00:00:00 2001 From: Irit Katriel <1055913+iritkatriel@users.noreply.github.com> Date: Wed, 20 Nov 2024 12:20:25 +0000 Subject: [PATCH 8/8] Update peps/pep-0765.rst --- peps/pep-0765.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst index 9881405d312..fc44f4bc60b 100644 --- a/peps/pep-0765.rst +++ b/peps/pep-0765.rst @@ -193,7 +193,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`` executes +``break`` and ``continue`` behave as they normally do when ``finally`` executes 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.