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
There seems to be a niche edge case where mypy detects a mismatch between parameter names for a ParamSpec but doesn't actually report the difference in parameter names. In my reproducible example, it actually prints a confusing error about the return types, even though the return types actually unify just fine. I've only been able to reproduce it with an async function, but I'm not sure if it's limited to async functions.
This is probably a relatively rare issue for users to hit because it involves a higher-order function that returns a decorator, ParamSpec, and async — all of which are somewhat niche on their own. However, the error output still seems very misleading to me.
Mypy should print an error pointing out that key2 takes a parameter named x while foo2 takes a parameter named y. For example, if you rewrote this example so that the foo2 is non-async and the decorator doesn't use Awaitable, you would get this error message:
error: Argument 1 has incompatible type "Callable[[Arg(int, 'y')], None]"; expected "Callable[[Arg(int, 'x')], None]" [arg-type]
Actual Behavior
Mypy gives an error that does not describe the difference in argument names, but which does describe a difference in return types (even though these return types actually unify just fine!):
error: Argument 1 has incompatible type "Callable[[int], Coroutine[Any, Any, None]]"; expected "Callable[[int], Awaitable[None]]" [arg-type]
Your Environment
Discovered while testing latest master to prepare the 1.15 release, but this behavior seems to be longstanding; I see the same error message when using the code from mypy v1.0.0. It seems to reproduce out of the box in Mypy, as demonstrated by the vanilla mypy playground link above.
The text was updated successfully, but these errors were encountered:
wesleywright
changed the title
Misleading error message when using ParamSpec with higher-order decorators
Misleading error message when using ParamSpec with higher-order decorators and async functions
Jan 20, 2025
…rn types in error messages (python#18495)
Fixespython#18493.
Improves message in python#12013 and python#4530, but probably still doesn't make it
clear enough.
Use higher verbosity for type formatting in error message if callables'
return types are compatible and supertype has some named arguments, as
that is a popular source of confusion.
Uh oh!
There was an error while loading. Please reload this page.
Bug Report
There seems to be a niche edge case where mypy detects a mismatch between parameter names for a
ParamSpec
but doesn't actually report the difference in parameter names. In my reproducible example, it actually prints a confusing error about the return types, even though the return types actually unify just fine. I've only been able to reproduce it with an async function, but I'm not sure if it's limited to async functions.This is probably a relatively rare issue for users to hit because it involves a higher-order function that returns a decorator,
ParamSpec
, and async — all of which are somewhat niche on their own. However, the error output still seems very misleading to me.To Reproduce
https://mypy-play.net/?mypy=latest&python=3.12&gist=12a1a49ced24294d0d1395f9317afcc1
Expected Behavior
Mypy should print an error pointing out that
key2
takes a parameter namedx
whilefoo2
takes a parameter namedy
. For example, if you rewrote this example so that thefoo2
is non-async and the decorator doesn't useAwaitable
, you would get this error message:Actual Behavior
Mypy gives an error that does not describe the difference in argument names, but which does describe a difference in return types (even though these return types actually unify just fine!):
Your Environment
Discovered while testing latest master to prepare the 1.15 release, but this behavior seems to be longstanding; I see the same error message when using the code from mypy v1.0.0. It seems to reproduce out of the box in Mypy, as demonstrated by the vanilla mypy playground link above.
The text was updated successfully, but these errors were encountered: