From c2f3540a974fa27608e5f184d3ec0278637b8c1f Mon Sep 17 00:00:00 2001 From: Irit Katriel Date: Tue, 19 Nov 2024 19:08:46 +0000 Subject: [PATCH] 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 =========