This PEP [1] proposes to allow unparenthesized except and except*
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.
The current syntax for catching multiple exceptions requires parentheses in the
except expression (equivalently for the except* expression). For
example:
While this syntax is clear and unambiguous, it can be seen as unnecessarily
verbose in some cases, especially when catching a large number of exceptions. By
allowing the omission of parentheses, we can simplify the syntax:
try:...exceptExceptionA,ExceptionB,ExceptionC:...
This change would bring the syntax more in line with other comma-separated lists
in Python, such as function arguments, generator expressions inside of a
function call, and tuple literals, where parentheses are optional.
The same change would apply to except* expressions. For example:
When using the as clause to capture the exception instance parentheses 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:
The decision to allow unparenthesized except blocks is based on the
following considerations:
Simplicity: Removing the requirement for parentheses simplifies the syntax,
making it more consistent with other parts of the language.
Readability: In cases where many exceptions are being caught, the removal of
parentheses can improve readability by reducing visual clutter.
Consistency: This change makes the except clause more consistent with
other parts of Python where unambiguous, comma-separated lists don’t require
parentheses.
This allows both the current parenthesized syntax and the new unparenthesized
syntax while requiring parentheses when the as keyword is used:
try:...except(ExceptionA,ExceptionB):# Still valid...exceptExceptionC,ExceptionD:# New syntax...except(ExceptionE,ExceptionF)ase:# 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
not.
This change is fully backwards compatible. All existing code using parenthesized
except and except* blocks will continue to work without modification.
The new syntax is purely additive and does not break any existing code.
It’s worth noting that in Python 2 the unparenthesized syntax was allowed with
two elements, but had different semantics, in which the first element of the
list was used as the exception type and the second element as the capture
variable. This change does not reintroduce the Python 2 semantics, and the
unparenthesized syntax will behave identically to the parenthesized version.
For experienced users, it can be introduced as a new, optional syntax that can
be used interchangeably with the parenthesized version. Documentation should
note that both forms are equivalent:
# These are equivalent:except(ValueError,TypeError):...exceptValueError,TypeError:...
It should be emphasized that this is purely a syntactic change and does not
affect the behaviour of exception handling.
A proof-of-concept implementation is available at
https://github.com/pablogsal/cpython/commits/notuples/. This implementation
modifies the Python parser to accept the new syntax and ensures that it behaves
identically to the parenthesized version.
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.
This document is placed in the public domain or under the
CC0-1.0-Universal license, whichever is more permissive.
You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.