Python Enhancement Proposals

Python »
PEP Index »
PEP 3110

PEP 3110 – Catching Exceptions in Python 3000

Author:: Collin Winter <collinwinter at google.com>
Status:

Abstract

This PEP introduces changes intended to help eliminate ambiguitiesin Python’s grammar, simplify exception classes, simplify garbagecollection for exceptions and reduce the size of the language inPython 3.0.

Rationale

except clauses in Python 2.x present a syntactic ambiguitywhere the parser cannot differentiate whether
```
except<expression>,<expression>:
```
should be interpreted as
```
except<type>,<type>:
```
or
```
except<type>,<name>:
```
Python 2 opts for the latter semantic, at the cost of requiring theformer to be parenthesized, like so
```
except(<type>,<type>):
```
As specified inPEP 352, the ability to treat exceptionsas tuples will be removed, meaning this code will no longer work
```
exceptos.error,(errno,errstr):
```
Because the automatic unpacking will no longer be possible, it isdesirable to remove the ability to use tuples asexcept targets.
As specified inPEP 344, exception instances in Python 3will possess a__traceback__ attribute. The Open Issues sectionof that PEP includes a paragraph on garbage collection difficultiescaused by this attribute, namely a “exception -> traceback ->stack frame -> exception” reference cycle, whereby all locals arekept in scope until the next GC run. This PEP intends to resolvethis issue by adding a cleanup semantic toexcept clauses inPython 3 whereby the target name is deleted at the end of theexcept suite.
In the spirit of“there should be one – and preferably only one– obvious way to do it”, it is desirable to consolidateduplicate functionality. To this end, theexc_value,exc_type andexc_traceback attributes of thesysmodule[1] will be removed in favor ofsys.exc_info(), which provides the same information. Theseattributes are already listed inPEP 3100 as targetedfor removal.

Grammar Changes

In Python 3, the grammar forexcept statements will changefrom[4]

except_clause:'except'[test[','test]]

except_clause:'except'[test['as'NAME]]

The use ofas in place of the comma token means that

except(AttributeError,os.error):

can be clearly understood as a tuple of exception classes. This newsyntax was first proposed by Greg Ewing[2] andendorsed ([2],[3]) by the BDFL.

Further, the restriction of the token followingas fromtesttoNAME means that only valid identifiers can be used asexcept targets.

Note that the grammar above always requires parenthesized tuples asexception classes. That way, the ambiguous

exceptA,B:

which would mean different things in Python 2.x and 3.x – leading tohard-to-catch bugs – cannot legally occur in 3.x code.

Semantic Changes

In order to resolve the garbage collection issue related toPEP 344,except statements in Python 3 will generate additional bytecode todelete the target, thus eliminating the reference cycle.The source-to-source translation, as suggested by Phillip J. Eby[5], is

try:try_bodyexceptEasN:except_body...

gets translated to (in Python 2.5 terms)

try:try_bodyexceptE,N:try:except_bodyfinally:N=NonedelN...

An implementation has already been checked into the py3k (formerly“p3yk”) branch[6].

Compatibility Issues

Nearly allexcept clauses will need to be changed.exceptclauses with identifier targets will be converted from

exceptE,N:

exceptEasN:

except clauses with non-tuple, non-identifier targets(e.g.,a.b.c[d]) will need to be converted from

exceptE,T:

exceptEast:T=t

Both of these cases can be handled by Guido van Rossum’s2to3utility[7] using theexcept fixer[8].

except clauses with tuple targets will need to be convertedmanually, on a case-by-case basis. These changes will usually needto be accompanied by changes to the exception classes themselves.While these changes generally cannot be automated, the2to3utility is able to point out cases where the target of anexceptclause is a tuple, simplifying conversion.

Situations where it is necessary to keep an exception instance aroundpast the end of theexcept suite can be easily translated like so

try:...exceptEasN:......

becomes

try:...exceptEasN:n=N......

This way, whenN is deleted at the end of the block,n willpersist and can be used as normal.

Lastly, all uses of thesys module’sexc_type,exc_valueandexc_traceback attributes will need to be removed. They can bereplaced withsys.exc_info()[0],sys.exc_info()[1] andsys.exc_info()[2] respectively, a transformation that can beperformed by2to3’ssysexcattrs fixer.

2.6 - 3.0 Compatibility

In order to facilitate forwards compatibility between Python 2.6 and 3.0,theexcept...as...: syntax will be backported to the 2.x series. Thegrammar will thus change from:

except_clause:'except'[test[','test]]

to:

except_clause:'except'[test[('as'|',')test]]

The end-of-suite cleanup semantic forexcept statements will not beincluded in the 2.x series of releases.

Open Issues

Replacing or Dropping “sys.exc_info()”

The idea of droppingsys.exc_info() or replacing it with asys.exception attribute or asys.get_exception() functionhas been raised several times on python-3000 ([9],[10]) and mentioned inPEP 344’s “Open Issues” section.

While a2to3 fixer to replace calls tosys.exc_info()and some attribute accesses would be trivial, it would be far moredifficult for static analysis to find and fix functions that expectthe values fromsys.exc_info() as arguments. Similarly, this doesnot address the need to rewrite the documentation for all APIs thatare defined in terms ofsys.exc_info().