New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unhelpful UnboundLocalError due to del'ing of exception target #61992
Comments
As described here: http://www.wefearchange.org/2013/04/python-3-language-gotcha-and-short.html the following code will produce an UnboundLocalError when the exception is triggered: def bad():
e = None
try:
do_something()
except KeyError as e:
print('ke')
except ValueError as e:
print('ve')
print(e) The reason is that the exception handling machinery del's Can we do better? What if instead of del'ing the target, we set it to None? We wouldn't get a ULE but the fact that print(e) would print None might be just as mysterious. Any other ideas? (BTW, there's likely nothing to be done for Python < 3.4.) |
Maybe we could raise a warning when the deleted name already exists in the local namespace? (FWIW I knew about the fact that the name gets deleted, and still managed to get bitten by it a couple of times.) |
On Apr 19, 2013, at 12:01 AM, Ezio Melotti wrote:
Ideally, I think a SyntaxError if you could detect a previously bound name in -Barry |
And what if it weren't a print statement? An error is better than a "randomly" changed value, I think. I'm really not sure there is anything we can do here, beyond Ezio's warning suggestion. |
This used to raise a SyntaxError. See bpo-4617. |
On Apr 19, 2013, at 12:37 AM, R. David Murray wrote:
Right. The point is, is it more helpful to have an unexpected value in the A warning would be fine. I just want to give programmers some help in trying |
It seems to me that this kind of dubious-but-legal code is what http://docs.python.org/3/library/exceptions.html#SyntaxWarning is designed to handle. Something like "SyntaxWarning: implicitly deleted exception variable referenced after end of except clause". |
It occurs to me that one of the problems here is that the UnboundLocalError only occurs when the except clause is executed. Do you think it would be helpful and acceptable (in 3.4, as it is a behavior change) to have the 'as' variable *always* deleted at the end of the try/except block? Then you would always get the UnboundLocalError, instead of it mysteriously appearing only when the except was executed. Granted it is a bit weird, but then so is the variable getting deleted in the first place. |
I don't think we want to mess with the control flow, as that would be even weirder and may interact strangely with else and finally clauses. A SyntaxWarning would be unconditional (so it doesn't matter whether or not the exception is triggered at run time), happens at compile time (so developers will see it), but won't be triggered when loading from a cached bytecode file (so end users typically won't see it). |
Attached a sketchy proof of concept. It only checks for locals, but it should probably check for globals too. Does the approach make sense? |
FWIW this has come up before: http://mail.python.org/pipermail/python-dev/2012-October/122504.html and relatedly: |
Ezio, the problem with your patch is that it also gives a warning on this code, which is totally safe: def good():
exc = None
try:
bar(int(sys.argv[1]))
except KeyError as e:
print('ke')
exc = e
except ValueError as e:
print('ve')
exc = e
print(exc) |
Attached a new patch that improves the following things:
There are still several problems though:
While compiling I got this warning: This comes from a code like: and in this case there shouldn't be any warning. A possible way to fix this is to keep a "whitelist" of locals that are first defined as an except target, but then it will still break if there's a |
PyUnicode_AsUTF8() |
I considered that, but is it guaranteed that the output encoding is UTF-8? What if the warning is printed on a Windows console that uses cp1252? I also considered encoding it and then use PyBytes_AsString, but I was hoping in something simpler (also I'm not sure where to get the right encoding). |
PyErr_WarnExplicit() calls PyUnicode_FromString() which made an inverse |
I think the issue is that the error message for UnboundLocalError is wrong, see this example: >>> def g():
... x = 42
... del x
... print(x)
...
>>> g()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in g
UnboundLocalError: local variable 'x' referenced before assignment
>>> How about we change it to "local variable 'x' referenced before assignment or after deletion"? |
Following a discussion on PR24976 we opted for "cannot access local variable 'x' where it is not associated with a value" This is because binding it not always related to assignment. I don't know whether this completely resolves this issue, or whether there is still something to change around the None-setting of except targets. |
I encountered the similar behavior unexpectedly when dealing with LEGB scope of names. Take the following example run under Python 3.9.2: def doSomething():
x = 10
del x
print(x)
x = 5
doSomething() This produces a UnboundLocalError at print(x) even though "x" can still be found in the global scope. Indeed if your add print(globals()) before the print(x) line, you can see "x" listed. By contrast, LEGB scope behavior works as expected in this example: def doSomething():
print(x)
x = 5
doSomething() The former example yielding the UnboundLocalError when dealing with name scope feels like a bug that lines up with the original behavior described in this enhancement request, as I believe "x" is still a bounded name in the global scope, but was explicitly deleted from the local scope. |
Aaron: Your understanding of how LEGB works in Python is a little off. Locals are locals for the *entire* scope of the function, bound or unbound; deleting them means they hold nothing (they're unbound) but del can't actually stop them from being locals. The choice of whether to look something up in the L, E or GB portions of LEGB scoping rules is a *static* choice made when the function is defined, and is solely about whether they are assigned to anywhere in the function (without an explicit nonlocal/global statement to prevent them becoming locals as a result). Your second example can be made to fail just by adding a line after the print: def doSomething():
print(x)
x = 1 and it fails for the same reason: def doSomething():
x = 10
del x
print(x) fails; a local is a local from entry to exit in a function. Failure to assign to it for a while doesn't change that; it's a local because you assigned to it at least once, along at least one code path. del-ing it after assigning doesn't change that, because del doesn't get rid of locals, it just empties them. Imagine how complex the LOAD_FAST instruction would get if it needed to handle not just loading a local, but when the local wasn't bound, had to choose *dynamically* between:
That's starting to stretch the definition of "fast" in LOAD_FAST. :-) |
Is this issue already resolved? |
Yes, #24976 as described in #61992 (comment) is the solution. Anyone wanting further change should open a new issue. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: