This PEP introduces changes intended to help eliminate ambiguities in Python’s grammar, simplify exception classes, simplify garbage collection for exceptions and reduce the size of the language in Python 3.0.
should be interpreted as
or
Python 2 opts for the latter semantic, at the cost of requiring the former to be parenthesized, like so
Because the automatic unpacking will no longer be possible, it is desirable to remove the ability to use tuples as except targets.
In Python 3, the grammar for except statements will change from [4]
to
The use of as in place of the comma token means that
can be clearly understood as a tuple of exception classes. This new syntax was first proposed by Greg Ewing [2] and endorsed ([2], [3]) by the BDFL.
Further, the restriction of the token following as from test to NAME means that only valid identifiers can be used as except targets.
Note that the grammar above always requires parenthesized tuples as exception classes. That way, the ambiguous
which would mean different things in Python 2.x and 3.x – leading to hard-to-catch bugs – cannot legally occur in 3.x code.
In order to resolve the garbage collection issue related to PEP 344, except statements in Python 3 will generate additional bytecode to delete the target, thus eliminating the reference cycle. The source-to-source translation, as suggested by Phillip J. Eby [5], is
gets translated to (in Python 2.5 terms)
An implementation has already been checked into the py3k (formerly “p3yk”) branch [6].
Nearly all except clauses will need to be changed. except clauses with identifier targets will be converted from
to
except clauses with non-tuple, non-identifier targets (e.g., a.b.c[d]) will need to be converted from
to
Both of these cases can be handled by Guido van Rossum’s 2to3 utility [7] using the except fixer [8].
except clauses with tuple targets will need to be converted manually, on a case-by-case basis. These changes will usually need to be accompanied by changes to the exception classes themselves. While these changes generally cannot be automated, the 2to3 utility is able to point out cases where the target of an except clause is a tuple, simplifying conversion.
Situations where it is necessary to keep an exception instance around past the end of the except suite can be easily translated like so
becomes
This way, when N is deleted at the end of the block, n will persist and can be used as normal.
Lastly, all uses of the sys module’s exc_type, exc_value and exc_traceback attributes will need to be removed. They can be replaced with sys.exc_info()[0], sys.exc_info()[1] and sys.exc_info()[2] respectively, a transformation that can be performed by 2to3’s sysexcattrs fixer.
In order to facilitate forwards compatibility between Python 2.6 and 3.0, the except ... as ...: syntax will be backported to the 2.x series. The grammar will thus change from:
to:
The end-of-suite cleanup semantic for except statements will not be included in the 2.x series of releases.
The idea of dropping sys.exc_info() or replacing it with a sys.exception attribute or a sys.get_exception() function has been raised several times on python-3000 ([9], [10]) and mentioned in PEP 344’s “Open Issues” section.
While a 2to3 fixer to replace calls to sys.exc_info() and some attribute accesses would be trivial, it would be far more difficult for static analysis to find and fix functions that expect the values from sys.exc_info() as arguments. Similarly, this does not address the need to rewrite the documentation for all APIs that are defined in terms of sys.exc_info().
This PEP was implemented in revisions 53342 [11] and 53349 [12]. Support for the new except syntax in 2.6 was implemented in revision 55446 [13].
This document has been placed in the public domain.
Source: https://github.com/python/peps/blob/main/peps/pep-3110.rst
Last modified: 2025-02-01 08:59:27 UTC