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
Overloads do not take type: ignore into account #12454
Ah sorry, I was being a bit unclear with my terminology: not sure how to say it exactly but that probably shouldn't fail (function -> overload shouldn't be a breaking change, imo).
Mainly, I'm referring to this that mypy uses to check overloads are ok not taking type ignores into account:
The error comes from line 18, which starts with run_job(. What about using a # type: ignore on that line instead? Like so:
run_job( # type: ignorejob,
"",
)
That doesn't solve the issue
error: Argument 1 to "run_job" has incompatible type "Job[[int], Optional[Awaitable[None]]]"; expected "Job[[int], Awaitable[None]]"
error: Argument 2 to "run_job" has incompatible type "str"; expected "int"
The first error is still wrong and now mypy doesn't ignore the second one anymore.
The only option other option would be this
run_job(job, "") # type: ignore[arg-type]
That would simply hide both errors instead of resolving the underlying issue. In the particular case it wouldn't be possible due to formatting constraints.
-- The tests are done with #11847 since mypy doesn't yet support generic ParamSpec.
Thought about this some more. I'm not sure how mypy, or any other type checker, is supposed to choose between overloads if one argument type is incorrect. Overloads simply depend on the arg-types. An even simpler example
Maybe I'm missing something, but I also don't think there's a bug here. mypy passes if you use this instead:
run_job( # type: ignore[call-overload]job,
"",
)
As @erictraut said, there is no notion of "passing" a type ignore into a call; the comment simply suppresses type errors on that line. In this case, we generate the error on the first line of the call, so that's where you have to put the ignore.
Activity
erictraut commentedon Mar 26, 2022
A
# type: ignorecomment simply suppresses errors on that line. It is not intended to "propagate" in any way.A5rocks commentedon Mar 26, 2022
Ah sorry, I was being a bit unclear with my terminology: not sure how to say it exactly but that probably shouldn't fail (function -> overload shouldn't be a breaking change, imo).
Mainly, I'm referring to this that mypy uses to check overloads are ok not taking type ignores into account:
mypy/mypy/checkexpr.py
Lines 1763 to 1771 in 14de8c6
If it should fail, my bad!
DevilXD commentedon Mar 26, 2022
The error comes from line 18, which starts with
run_job(. What about using a# type: ignoreon that line instead? Like so:cdce8p commentedon Mar 26, 2022
That doesn't solve the issue
The first error is still wrong and now mypy doesn't ignore the second one anymore.
The only option other option would be this
That would simply hide both errors instead of resolving the underlying issue. In the particular case it wouldn't be possible due to formatting constraints.
--
The tests are done with #11847 since mypy doesn't yet support generic ParamSpec.
cdce8p commentedon Mar 27, 2022
Thought about this some more. I'm not sure how mypy, or any other type checker, is supposed to choose between overloads if one argument type is incorrect. Overloads simply depend on the arg-types. An even simpler example
What should mypy infer here? Currently it's
Any, probably the best we can do. Pyright infersUnknownwhich is also an option.I think we can close this issue.
JelleZijlstra commentedon Mar 27, 2022
Maybe I'm missing something, but I also don't think there's a bug here. mypy passes if you use this instead:
As @erictraut said, there is no notion of "passing" a type ignore into a call; the comment simply suppresses type errors on that line. In this case, we generate the error on the first line of the call, so that's where you have to put the ignore.