This patch implements the proposal outlined on the py3k mailing-listhere:http://mail.python.org/pipermail/python-3000/2008-May/013740.htmlIt solves both#2507 and#2833, and even improves re-raising semanticsin several cases (see the test cases which were added to test_raise.py).Anothing thing worth noting is that f_exc_* fields are not accessiblefrom Python code anymore, because their semantics is an implementationdetail and shouldn't be relied upon.

PEP 3134's implicit exception chaining (if accepted) would require yoursemantic, and your semantic is simpler anyway (even if theimplementation is non-trivial), so consider my objections to be dropped.PEP 3134 also proposes implicit chaining during a finally block, whichraises questions for this case:try:    ...finally:    print(sys.exc_info())    raiseIf sys.exc_info() were removed (with no direct replacement) we'd havethat behaviour answered.  raise could be answered by making it a syntaxerror, but keep in mind this may be nested in another except block:try:    ...except:    try:        ...    finally:        raiseI'd prefer a syntax error in this case as well, to avoid any ambiguityand to keep the implementation simple.

With or without my patch, bare "raise" inside a "finally" statementraises a "RuntimeError: no active exception to re-raise". (except, ofcourse, when the try/finally is itself enclosed in an except block)That's because a finally block is not considered an exception handler. Idon't think there's any reason to change this.I'm not for adding syntax errors. After all the bare "raise" statementjust does the moral equivalent of re-raising sys.exc_info() verbatim. Inthose 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 hasbecome 5-10% faster under Linux, witnessed with pystone and pybench. Idon't know the explanation)

PEP 3134 gives reason to change it.  __context__ should be set fromwhatever exception is "active" from the try/finally, thus it should bethe inner block, not the outer except block.This flipping of behaviour, and the general ambiguity, is why I suggesta syntax error.  "In the face of ambiguity, refuse the temptation to guess."PEP 3134 has not been officially accepted, but many parts have be addedanyway.  Your cleanups pave the way for the last of it.  I suggestasking on python-3000 for a pronouncement on the PEP.

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

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

Here is a newer patch that also adapts the behaviour of finally blocksas suggested by Adam Olsen. Note that I had to change some things in theway '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 inr64121.