Abstract

This PEP[1] proposes to allow unparenthesizedexcept andexcept*blocks in Python’s exception handling syntax only when not using theasclause. Currently, when catching multiple exceptions, parentheses are requiredaround the exception types. This was a Python 2 remnant. This PEP suggests allowingthe omission of these parentheses, simplifying the syntax, making it more consistentwith other parts of the syntax that make parentheses optional, and improving readabilityin certain cases.

Motivation

The current syntax for catching multiple exceptions requires parentheses in theexcept expression (equivalently for theexcept* expression). Forexample:

try:...except(ExceptionA,ExceptionB,ExceptionC):...

While this syntax is clear and unambiguous, it can be seen as unnecessarilyverbose in some cases, especially when catching a large number of exceptions. Byallowing 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 listsin Python, such as function arguments, generator expressions inside of afunction call, and tuple literals, where parentheses are optional.

The same change would apply toexcept* expressions. For example:

try:...except*ExceptionA,ExceptionB,ExceptionC:...

When using theas clause to capture the exception instance parentheses mustbe used as before. Some users have expressed that they would find it confusing notto require parentheses as it would be unclear what exactly is being assigned tothe target since in other parts of the language multipleas clauses can be usedin similar situations (like in imports and context managers). This means that ifanas clause its being added to the previous example it must be done as:

try:...except(ExceptionA,ExceptionB,ExceptionC)ase:...

Rationale

The decision to allow unparenthesizedexcept blocks is based on thefollowing considerations:

1. Simplicity: Removing the requirement for parentheses simplifies the syntax,making it more consistent with other parts of the language.
2. Readability: In cases where many exceptions are being caught, the removal ofparentheses can improve readability by reducing visual clutter.
3. Consistency: This change makes theexcept clause more consistent withother parts of Python where unambiguous, comma-separated lists don’t requireparentheses.

Specification

The syntax for the except clause will be modified to allow an unparenthesizedlist of exception types. The grammar will be updated as follows:

except_block:|'except'expressions':'block|'except'expression'as'NAME':'block|'except'':'blockexcept_star_block|'except''*'expressions':'block|'except''*'expression'as'NAME':'block

This allows both the current parenthesized syntax and the new unparenthesizedsyntax while requiring parentheses when theas 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 catchany of the listed exceptions, regardless of whether they are parenthesized ornot.

Backwards Compatibility

This change is fully backwards compatible. All existing code using parenthesizedexcept andexcept* 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 withtwo elements, but had different semantics, in which the first element of thelist was used as the exception type and the second element as the capturevariable. This change does not reintroduce the Python 2 semantics, and theunparenthesized syntax will behave identically to the parenthesized version.

Security Implications

There are no known security implications for this change. The semantics ofexception handling remain the same, and this is purely a syntactic change.

How to Teach This

For new Python users, the unparenthesized syntax can be taught as the standardway to catch multiple exceptions:

try:risky_operation()exceptValueError,TypeError,OSError:handle_errors()

For experienced users, it can be introduced as a new, optional syntax that canbe used interchangeably with the parenthesized version. Documentation shouldnote 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 notaffect the behaviour of exception handling.

Reference Implementation

A proof-of-concept implementation is available athttps://github.com/pablogsal/cpython/commits/notuples/. This implementationmodifies the Python parser to accept the new syntax and ensures that it behavesidentically to the parenthesized version.

Rejected Ideas

1. Allowing mixed parenthesized and unparenthesized syntax:

   try:...except(ValueError,TypeError),OSError:...

   This was rejected due to the potential for confusion and to maintain a cleardistinction between the two styles.

Deferred Ideas

1. Allowing unparenthesized expressions when theas keyword is used. The reasonwe have decided to defer this particular form given that there isn’t clearconsensus either way and there are reasonable arguments for both positions, the safestapproach is keeping the parentheses requirement since it can be removed later if usersfind the disconnect too acute, while taking it out and users deciding it was a bad ideadoesn’t make it easy to put back.

Footnotes

Copyright

This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.