Issue 3021: Lexical exception handlers

This patch implements the proposal outlined on the py3k mailing-list
here: http://mail.python.org/pipermail/python-3000/2008-May/013740.html

It solves both #2507 and #2833, and even improves re-raising semantics
in several cases (see the test cases which were added to test_raise.py).

Anothing thing worth noting is that f_exc_* fields are not accessible
from Python code anymore, because their semantics is an implementation
detail and shouldn't be relied upon.

PEP 3134's implicit exception chaining (if accepted) would require your
semantic, and your semantic is simpler anyway (even if the
implementation is non-trivial), so consider my objections to be dropped.

PEP 3134 also proposes implicit chaining during a finally block, which
raises questions for this case:

try:
    ...
finally:
    print(sys.exc_info())
    raise

If sys.exc_info() were removed (with no direct replacement) we'd have
that behaviour answered.  raise could be answered by making it a syntax
error, but keep in mind this may be nested in another except block:

try:
    ...
except:
    try:
        ...
    finally:
        raise

I'd prefer a syntax error in this case as well, to avoid any ambiguity
and to keep the implementation simple.

With or without my patch, bare "raise" inside a "finally" statement
raises a "RuntimeError: no active exception to re-raise". (except, of
course, when the try/finally is itself enclosed in an except block)
That's because a finally block is not considered an exception handler. I
don't think there's any reason to change this.

I'm not for adding syntax errors. After all the bare "raise" statement
just does the moral equivalent of re-raising sys.exc_info() verbatim. In
those situations where sys.exc_info() would return a non-empty result,
why shouldn't "raise" be accepted as well?

(an unexpected side effect of my patch is that the interpreter has
become 5-10% faster under Linux, witnessed with pystone and pybench. I
don't know the explanation)

PEP 3134 gives reason to change it.  __context__ should be set from
whatever exception is "active" from the try/finally, thus it should be
the inner block, not the outer except block.

This flipping of behaviour, and the general ambiguity, is why I suggest
a syntax error.  "In the face of ambiguity, refuse the temptation to guess."

PEP 3134 has not been officially accepted, but many parts have be added
anyway.  Your cleanups pave the way for the last of it.  I suggest
asking on python-3000 for a pronouncement on the PEP.

Ok, it makes sense to have the same behaviour for except and finally
blocks then. As for the syntax error, I'm still not convinced. The point
of Py3k is to change semantics: people should expect some incompatible
changes. Also the previous behaviour was rather under-specified, so it
could be considered a bug. And it seems to me syntax errors should be
used to guard against potential syntax mistakes, not semantic subtleties.

I agree, the argument for a syntax error is weak.  It's more instinct
than anything else.  I don't think I'd be able to convince you unless
Guido had the same instinct I do. ;)

Here is a newer patch that also adapts the behaviour of finally blocks
as suggested by Adam Olsen. Note that I had to change some things in the
way 'with' statements are compiled and executed.

Guido has given the go ahead on this. I will apply in about 8 hours
(after some sleep).

Commited in r64121.