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.

Python 2 opts for the latter semantic, at the cost of requiring the
former to be parenthesized, like so

except (<type>, <type>):

As specified in
PEP 352
[1]
, the ability to treat exceptions
as tuples will be removed, meaning this code will no longer work

except os.error, (errno, errstr):

Because the automatic unpacking will no longer be possible, it is
desirable to remove the ability to use tuples as
except
targets.

As specified in
PEP 344
[5]
, exception instances in Python 3
will possess a
__traceback__
attribute. The Open Issues section
of that PEP includes a paragraph on garbage collection difficulties
caused by this attribute, namely a "exception -> traceback ->
stack frame -> exception" reference cycle, whereby all locals are
kept in scope until the next GC run. This PEP intends to resolve
this issue by adding a cleanup semantic to
except
clauses in
Python 3 whereby the target name is deleted at the end of the
except
suite.

In the spirit of "there should be one -- and preferably only one
-- obvious way to do it"
[2]
, it is desirable to consolidate
duplicate functionality. To this end, the
exc_value
,
exc_type
and
exc_traceback
attributes of the
sys
module
[3]
will be removed in favor of
sys.exc_info()
, which provides the same information. These
attributes are already listed in
PEP 3100
[4]
as targeted
for removal.

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
[9]
, is

Nearly all
except
clauses will need to be changed.
except
clauses with identifier targets will be converted from

except E, N:

to

except E as N:

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

except E, T:

to

except E as t:
T = t

Both of these cases can be handled by Guido van Rossum's
2to3
utility
[11]
using the
except
fixer
[12]
.

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

try:
...
except E as N:
...
...

becomes

try:
...
except E as N:
n = N
...
...

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.

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 (
[13]
,
[14]
) 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()
.