[issue3021] Lexical exception handlers
Benjamin Peterson [EMAIL PROTECTED] added the comment: Commited in r64121. -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
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] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
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 PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
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/finally.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
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 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. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
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 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? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
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 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. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
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 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. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
Changes by Adam Olsen [EMAIL PROTECTED]: -- nosy: +Rhamphoryncus ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3021] Lexical exception handlers
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
