-
-
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
assert_type: Use fully qualified types when names are ambiguous #12677
Comments
I don't know if this is the exact same bug or not, but I just discovered that this code: from typing_extensions import assert_type
assert_type(42, int) fails to typecheck with mypy (both 0.960 and commit 1636a05) with the following message:
|
@jwodder wow that's unfortunate. I think it's a different problem though, could you open a new issue? |
@JelleZijlstra Issue created: #12923 |
Implementation hints: to fix this, it may be sufficient to use |
Hi! Is this issue still open? I would like to work on it. |
Yes! Jukka's message above should provide a way to fix the issue. Feel free to ask here if you have any questions. |
from typing import TypeVar
import typing
import typing_extensions
U = TypeVar("U", int, typing_extensions.SupportsIndex)
def f(si: U) -> U:
return si
def caller(si: typing.SupportsIndex):
typing_extensions.assert_type(f(si), typing.SupportsIndex) This code doesn't produce any errors in current master branch. Is this fixed already or should the behavior be outputing the fully qualified names? |
The original repro case is a bit convoluted, not sure why I didn't do something simpler. However, consider this case: import typing_extensions
class SupportsIndex:
pass
def f(si: SupportsIndex):
typing_extensions.assert_type(si, typing_extensions.SupportsIndex) This still produces I would want it to say something like |
Fixes #12677 When assert_type fails, when the type of value examined and the specified type have the same name, mypy returns an error with more descriptive and distinct names.
On current master, this code:
produces
This is arguably correct, since the expression is of type
typing_extensions.SupportsIndex
and we wantedtyping.SupportsIndex
, but obviously the UX is terrible. We should output the fully qualified names.More broadly, perhaps
assert_type()
should consider two protocols that define identical methods to be the same (so the assertion should pass). Curious what other people think here.The text was updated successfully, but these errors were encountered: