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
{{ message }}
Repository navigation
Covariance error inferred for lambda has invalid line number associated with it #8592
Running mypy on first clean run (without .mypy_cache) has the following output:
example.py:1276: error: Cannot use a covariant type variable as a parameter
Found 1 error in 1 file (checked 1 source file)
For some reason, mypy sees error on line 1276 which does not exist. On the other hand, running mypy for the second time gives:
Success: no issues found in 1 source file
What's more, when you have pretty set to True, first run gives:
Traceback (most recent call last):
File "/home/krprzyby/.local/bin/mypy", line 8, in <module>
sys.exit(console_entry())
File "/home/krprzyby/.local/lib/python3.8/site-packages/mypy/__main__.py", line 8, in console_entry
main(None, sys.stdout, sys.stderr)
File "mypy/main.py", line 89, in main
File "mypy/build.py", line 180, in build
File "mypy/build.py", line 249, in _build
File "mypy/build.py", line 2649, in dispatch
File "mypy/build.py", line 2956, in process_graph
File "mypy/build.py", line 3073, in process_stale_scc
File "mypy/errors.py", line 476, in file_messages
File "mypy/errors.py", line 449, in format_messages
IndexError: list index out of range
Running mypy for the second time works correctly with pretty set to True because the line number is correct and # type: ignore works.
Also, for anyone that faces similar issue when using this recipe from hypothesis documentation, here's a working solution that avoids any mypy errors and do not require # type: ignore
I think the problem is that the check for whether a covariant type variable is used as the argument to a function reports the line number that the type variable is bound to a variable (which makes sense when that type variable is an argument for a FuncDef but doesn't make sense for a Callable variable or a lambda).
The wrong line number (which was line 884 in my case) seems to be pointing here.
I managed to create a somewhat simpler example:
fromtypingimportAny, Callable, TypeVarEx=TypeVar("Ex")
T=TypeVar("T", covariant=True)
deftakes_lambda(func: Callable[[Ex], Any]) ->None:
passdeftest(a: T) ->None: # E: Cannot use a covariant type variable as a parameterfunc: Callable[[T], Any]
takes_lambda(func) # type: ignore
Activity
kprzybyla commentedon Mar 25, 2020
Also, for anyone that faces similar issue when using this recipe from
hypothesisdocumentation, here's a working solution that avoids anymypyerrors and do not require# type: ignoreilevkivskyi commentedon Mar 27, 2020
Wrong line number for error is a pretty serious issue, hard to say what is a possible root cause however.
pranavrajpal commentedon Aug 12, 2021
I think the problem is that the check for whether a covariant type variable is used as the argument to a function reports the line number that the type variable is bound to a variable (which makes sense when that type variable is an argument for a
FuncDefbut doesn't make sense for aCallablevariable or a lambda).The wrong line number (which was line 884 in my case) seems to be pointing here.
I managed to create a somewhat simpler example:
Do not use types as error contexts during type checking (python#22156)