From 922f0fb15a5e09f1d85258955bc0b14e67cb8de7 Mon Sep 17 00:00:00 2001 From: Pablo Galindo Salgado Date: Sat, 19 Oct 2024 20:41:51 +0100 Subject: [PATCH] PEP 758: Force parentheses when using 'as' (#4073) --- peps/pep-0758.rst | 42 ++++++++++++++++++++++++++++++------------ 1 file changed, 30 insertions(+), 12 deletions(-) diff --git a/peps/pep-0758.rst b/peps/pep-0758.rst index d0c7f4050..9a9369117 100644 --- a/peps/pep-0758.rst +++ b/peps/pep-0758.rst @@ -12,12 +12,12 @@ Abstract ======== This PEP [1]_ proposes to allow unparenthesized ``except`` and ``except*`` -blocks in Python's exception handling syntax. Currently, when catching multiple -exceptions, parentheses are required around the exception types. This was a -Python 2 remnant. This PEP suggests allowing the omission of these parentheses, -simplifying the syntax, making it more consistent with other parts of the syntax -that make parentheses optional, and improving readability in certain cases. - +blocks in Python's exception handling syntax only when not using the ``as`` +clause. Currently, when catching multiple exceptions, parentheses are required +around the exception types. This was a Python 2 remnant. This PEP suggests allowing +the omission of these parentheses, simplifying the syntax, making it more consistent +with other parts of the syntax that make parentheses optional, and improving readability +in certain cases. Motivation ========== @@ -57,14 +57,18 @@ The same change would apply to ``except*`` expressions. For example: except* ExceptionA, ExceptionB, ExceptionC: ... -Both forms will also allow the use of the ``as`` clause to capture the exception -instance as before: +When using the ``as`` clause to capture the exception instance paretheses must +be used as before. Some users have expressed that they would find it confusing not +to require parentheses as it would be unclear what exactly is being assigned to +the target since in other parts of the language multiple ``as`` clauses can be used +in similar situations (like in imports and context managers). This means that if +an ``as`` clause its being added to the previous example it must be done as: .. code-block:: python try: ... - except ExceptionA, ExceptionB, ExceptionC as e: + except (ExceptionA, ExceptionB, ExceptionC) as e: ... @@ -93,14 +97,16 @@ list of exception types. The grammar will be updated as follows: .. code-block:: peg except_block: - | 'except' expressions ['as' NAME] ':' block + | 'except' expressions ':' block + | 'except' expression 'as' NAME ':' block | 'except' ':' block except_star_block - | 'except' '*' expressions ['as' NAME] ':' block + | 'except' '*' expressions ':' block + | 'except' '*' expression 'as' NAME ':' block This allows both the current parenthesized syntax and the new unparenthesized -syntax: +syntax while requiring parentheses when the ``as`` keyword is used: .. code-block:: python @@ -110,6 +116,8 @@ syntax: ... except ExceptionC, ExceptionD: # New syntax ... + except (ExceptionE, ExceptionF) as e: # Parentheses still required + ... The semantics of exception handling remain unchanged. The interpreter will catch any of the listed exceptions, regardless of whether they are parenthesized or @@ -191,6 +199,16 @@ Rejected Ideas This was rejected due to the potential for confusion and to maintain a clear distinction between the two styles. +Deferred Ideas +============== + +1. Allowing unparenthesized expressions when the ``as`` keyword is used. The reason + we have decided to defer this particular form given that there isn't clear + consensus either way and there are reasonable arguments for both positions, the safest + approach is keeping the parentheses requirement since it can be removed later if users + find the disconnect too acute, while taking it out and users deciding it was a bad idea + doesn’t make it easy to put back. + Footnotes =========