-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
False positive unreachable with redefined variable in loop #8865
Comments
The loop is unrolled one cycle, so we can initialize `ret` to a set from the start. Besides helping mypy, it is also a bit more efficient. python/mypy#8865
Does |
Yes, which is further evidence that the problem is in the order in which mypy does things: it seems to flag the code as unreachable before the final type for |
I stumbled over this and created a minimal example:
The last line contains an error. The variable Tested with Mypy 0.812 on Python 3.6.9. |
I've got a slightly more minimal test case for what I think is the same problem: def check_sorted(items: list[int]) -> None:
prev = None
for item in items:
reveal_type(prev)
assert prev is None or prev <= item
prev = item
reveal_type(prev) Output of mypy 1.8.0:
Expected output:
It seems mypy is able to correctly infer the type of |
Fixes python#18348 Fixes python#13973 Fixes python#11612 Fixes python#8721 Fixes python#8865 Fixes python#7204 I manually checked all the listed issues. Some of them were already partly fixed by python#18180.
When checking the following code:
mypy reports:
This statement is the
ret &= elem
inside theelse
block.It seems that mypy is using the initial type of
ret
to conclude thatret is None
is always true, ignoring the fact that inside the loopret
is redefined to a different type.If I place a
reveal_type
just before thereturn
, mypy does reportUnion[builtins.set[T`-1], None]
as the type, so it figures out the redefinition eventually.I'm using mypy 0.770 on Pyton 3.8.2, with the
--warn-unreachable
flag.The text was updated successfully, but these errors were encountered: