[issue3021] Lexical exception handlers

2008-06-11 Thread Benjamin Peterson
Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Commited in r64121. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3021] Lexical exception handlers

2008-06-10 Thread Benjamin Peterson
Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Guido has given the go ahead on this. I will apply in about 8 hours (after some sleep). -- assignee: -> benjamin.peterson resolution: -> accepted ___ Python tracker <[EMAIL PROTECTED]>

[issue3021] Lexical exception handlers

2008-06-07 Thread Antoine Pitrou
Antoine Pitrou <[EMAIL PROTECTED]> added the comment: 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. Added file: http://bugs.python.org/file10547/fina

[issue3021] Lexical exception handlers

2008-06-06 Thread Adam Olsen
Adam Olsen <[EMAIL PROTECTED]> added the comment: 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. ;) ___ Python tracker <[EMAIL PROTEC

[issue3021] Lexical exception handlers

2008-06-06 Thread Antoine Pitrou
Antoine Pitrou <[EMAIL PROTECTED]> added the comment: 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 beh

[issue3021] Lexical exception handlers

2008-06-06 Thread Adam Olsen
Adam Olsen <[EMAIL PROTECTED]> added the comment: 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

[issue3021] Lexical exception handlers

2008-06-06 Thread Antoine Pitrou
Antoine Pitrou <[EMAIL PROTECTED]> added the comment: (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) ___ Python tracker <[EMAIL PROTECTED]> <

[issue3021] Lexical exception handlers

2008-06-06 Thread Antoine Pitrou
Antoine Pitrou <[EMAIL PROTECTED]> added the comment: 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

[issue3021] Lexical exception handlers

2008-06-06 Thread Adam Olsen
Adam Olsen <[EMAIL PROTECTED]> added the comment: 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 d

[issue3021] Lexical exception handlers

2008-06-02 Thread Adam Olsen
Changes by Adam Olsen <[EMAIL PROTECTED]>: -- nosy: +Rhamphoryncus ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list maili

[issue3021] Lexical exception handlers

2008-06-01 Thread Benjamin Peterson
Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs

[issue3021] Lexical exception handlers

2008-06-01 Thread Antoine Pitrou
New submission from Antoine Pitrou <[EMAIL PROTECTED]>: 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 te