Repository navigation
Lexical exception handlers #47271
Description
| BPO | 3021 |
|---|---|
| Nosy | @pitrou, @benjaminp |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/benjaminp'
closed_at = <Date 2008-06-11.16:00:24.115>
created_at = <Date 2008-06-01.20:03:45.121>
labels = ['interpreter-core', 'type-bug']
title = 'Lexical exception handlers'
updated_at = <Date 2008-06-11.16:00:24.088>
user = 'https://github.com/pitrou'bugs.python.org fields:
activity = <Date 2008-06-11.16:00:24.088>
actor = 'benjamin.peterson'
assignee = 'benjamin.peterson'
closed = True
closed_date = <Date 2008-06-11.16:00:24.115>
closer = 'benjamin.peterson'
components = ['Interpreter Core']
creation = <Date 2008-06-01.20:03:45.121>
creator = 'pitrou'
dependencies = []
files = ['10495', '10547']
hgrepos = []
issue_num = 3021
keywords = ['patch']
message_count = 10.0
messages = ['67598', '67782', '67789', '67790', '67795', '67800', '67801', '67816', '67938', '67989']
nosy_count = 3.0
nosy_names = ['Rhamphoryncus', 'pitrou', 'benjamin.peterson']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue3021'
versions = ['Python 3.0']
Activity
pitrou commentedon Jun 1, 2008
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 bpo-2507 and bpo-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.
Rhamphoryncus commentedon Jun 6, 2008
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.
pitrou commentedon Jun 6, 2008
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?
pitrou commentedon Jun 6, 2008
(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)
Rhamphoryncus commentedon Jun 7, 2008
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.
pitrou commentedon Jun 7, 2008
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.
Rhamphoryncus commentedon Jun 7, 2008
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. ;)
pitrou commentedon Jun 7, 2008
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.
benjaminp commentedon Jun 11, 2008
Guido has given the go ahead on this. I will apply in about 8 hours
(after some sleep).
benjaminp commentedon Jun 11, 2008
Commited in r64121.