Repository navigation
Mypy incorrectly requires __next__() on the iterable of a for loop (regression from 0.942). #16733
Description
Bug Report
For loops in Python require only an iterable, for which an iterator is subsequently created. However, in the code below, Mypy incorrectly requires __next__ to be available on the iterable.
To Reproduce
from collections.abc import Iterable
xs: zip[tuple[object, ...]] | Iterable[object] = zip(*[[0], [0]])
for x in xs: passActual Behavior
main.py:4: error: "Iterable[object]" has no attribute "__next__" [attr-defined]Your Environment
- Mypy version used: 1.8.0.
- Mypy command-line flags: None.
- Mypy configuration options from
mypy.ini(and other config files): None. - Python version used: 3.12.
This is a regression from version 0.942.
1.8.0 Playground
0.942 Playground
Activity
graingert commentedon Jan 2, 2024
I can repeat this on 0.800, so I think it's just that zip changed definition in typeshed after 0.942
https://mypy-play.net/?mypy=0.800&python=3.12&gist=94e05458b907384b70af1be75c60cfeb
JamesParrott commentedon Jan 3, 2024
I can recreate this in v1.8.0 too. But interestingly there's no error with either type hint alone. The both annotations together with the
|is causing the bug.hauntsaninja commentedon Jan 4, 2024
Thanks for the issue!
It looks like mypy isn't handling the self type annotation on
zip.__iter__correctly. It loses track of the upper bound implied by the self type, so it gets the wrong return type when trying to resolve__iter__inmypy/mypy/checker.py
Line 4795 in 5350c0e
This looked familiar to me and it turns out I have a relevant patch in #13221. That patch would indeed fix this case, but for reasons beyond my understanding that patch makes mypy pretty unhappy in general.
Maybe @ilevkivskyi has time to take a look, since he made #16184 which solved the issue #13221 was trying to solve, and also is generally awesome at fixing things.
ilevkivskyi commentedon Feb 12, 2025
I am not sure what happened here, but this issue looks solved on current master.