-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Tuple types don't work with higher level typing #16935
Labels
bug
mypy got something wrong
Comments
Same issue with |
am having a go at this in https://github.com/urnest/mypy/tree/issue-16935 |
urnest
added a commit
to urnest/mypy
that referenced
this issue
May 12, 2024
... so e.g. reveal_type(tuple[int, int]) gives expected def (p0: builtins.int, p1: builtins.int) -> tuple[builtins.int, builtins.int] ... rather than def [_T_co] (typing.Iterable[_T_co`1] =) -> builtins.tuple[_T_co`1, ...]
urnest
added a commit
to urnest/mypy
that referenced
this issue
May 12, 2024
... so e.g. reveal_type(tuple[int, int]) gives expected def (p0: builtins.int, p1: builtins.int) -> tuple[builtins.int, builtins.int] ... rather than def [_T_co] (typing.Iterable[_T_co`1] =) -> builtins.tuple[_T_co`1, ...]
urnest
added a commit
to urnest/mypy
that referenced
this issue
Jun 1, 2024
…back i.e. the mypy type of the expression union[str, int] is a CallableType with fallback builtins.type this matches the mypy type of the expression int which is a CallableType with fallback builtins.type (suggested by PR review discussion)
urnest
added a commit
to urnest/mypy
that referenced
this issue
Jun 1, 2024
…back ... the original fallback ABCMeta is "correct" in that it aligns with the (abstract) base class of builtins.tuple. But rather than explicitly specify abc.ABCMeta as fallback, use the same fallback as the type we're applying arguments to (and that is abc.ABCMeta in our "tuple" case)
JelleZijlstra
pushed a commit
that referenced
this issue
Jun 3, 2024
implement the mypy/checkexpr.py TODO: Specialize the callable for the type arguments ... so e.g. reveal_type(tuple[int, int]) gives expected def (p0: tuple[builtins.int, builtins.int]) -> tuple[builtins.int, builtins.int] ... rather than def [_T_co] (typing.Iterable[_T_co`1] =) -> builtins.tuple[_T_co`1, ...] Fixes #16935
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
mypy 1.8.0, python 3.10.10
So tuple types get matched and checked normally in simple situations like this:
But imagine I want to define a function that takes a type and returns a value of that type (e.g. by deserializing something as the given type):
This works with builtin types, or with generics like
List
:... but not with tuples:
Trying to reveal the type of
Tuple
itself leads to strange results too (compared toList[...]
):So the question is, why does
Tuple
get a special treatment, and is there a way to make it behave like other generics?The text was updated successfully, but these errors were encountered: