You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are you reporting a bug, or opening a feature request?
Feature request
Please insert below the code you are checking with mypy,
or a mock-up repro if the source is private. We would appreciate
if you try to simplify your case to a minimal repro.
I found a case in my code recently where I had a typed function that had an UnboundLocalError - one of the branches used a variable that was undefined, but the same name was used in another place so mypy just assumed that it would be written before it was read. A simplified version would be like this:
def g(a,b):
# type: (bool, bool) -> None
if a:
for m in [1,2]:
pass
if b:
return m # bug here
Another related scenario (credit: @gvanrossum for this code):
def g(b):
# type: (bool) -> None
if b:
x = 1
y = x # Here we don't actually know whether x exists
I would like mypy to detect these as bugs. In particular it would probably make sense if there were a flag like --strict-optional for this - given that this behavior probably would break existing projects if it were on by default. I would like any variable that mypy can't prove is assigned before use to be an error; if mypy can't prove a variable is written before use, even if it is, I'd consider that poorly-written code. I suppose I just expect some basic control-flow analysis - once a variable is written, it's available to all lines in the same basic block, and any basic block that can only be reached by a basic block that assigns that local.
The text was updated successfully, but these errors were encountered:
dgoldstein0
changed the title
mypy error when code might raise UnboundLocalError
mypy should error when code might raise UnboundLocalError
Oct 2, 2018
another minor point: with statements can technically swallow these errors, e.g. with self.assertRaises(...): and similar. That said I don't really see a use case for where typechecked code should allow UnboundLocalErrors at runtime - it's nice to be able to swallow errors from called functions (e.g. try... except Exception: pass or similar patterns) but if mypy can see a possible error of the unbound local kind, it should probably say something.
Feature request
or a mock-up repro if the source is private. We would appreciate
if you try to simplify your case to a minimal repro.
I found a case in my code recently where I had a typed function that had an UnboundLocalError - one of the branches used a variable that was undefined, but the same name was used in another place so mypy just assumed that it would be written before it was read. A simplified version would be like this:
Another related scenario (credit: @gvanrossum for this code):
An even simpler case from @ilevkivskyi:
Mypy doesn't give errors about this code
I would like mypy to detect these as bugs. In particular it would probably make sense if there were a flag like --strict-optional for this - given that this behavior probably would break existing projects if it were on by default. I would like any variable that mypy can't prove is assigned before use to be an error; if mypy can't prove a variable is written before use, even if it is, I'd consider that poorly-written code. I suppose I just expect some basic control-flow analysis - once a variable is written, it's available to all lines in the same basic block, and any basic block that can only be reached by a basic block that assigns that local.
The text was updated successfully, but these errors were encountered: