Skip to content
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

(🐞) False positive "error: Type application has too many types (1 expected)" on tuple when annotated as a type or in a TypeAlias with new union syntax (PEP 604) #11098

Closed
Tracked by #4819
KotlinIsland opened this issue Sep 13, 2021 · 13 comments · Fixed by #14184
Labels
affects-typeshed Anything that blocks a typeshed change bug mypy got something wrong priority-0-high topic-pep-585 PEP 585 (builtin generics) topic-pep-604 PEP 604 (union | operator) topic-type-alias TypeAlias and other type alias issues

Comments

@KotlinIsland
Copy link
Contributor

KotlinIsland commented Sep 13, 2021

mypy 0.910

a: type = tuple[int] # no error
b = tuple[int] # no error
c = tuple[int, int] # no error
error: type = tuple[int, int] # error: Type application has too many types (1 expected)

also on functions attributes:

def foo(tp: type): ...

foo(tuple[int, int])

also when in a new union syntax type alias:

A = str | tuple[str, str]  # error: Type application has too many types (1 expected)

https://mypy-play.net/?mypy=latest&python=3.10&flags=strict%2Ccheck-untyped-defs%2Cdisallow-any-decorated%2Cdisallow-any-expr%2Cdisallow-any-explicit%2Cdisallow-any-generics%2Cdisallow-any-unimported%2Cdisallow-incomplete-defs%2Cdisallow-subclassing-any%2Cdisallow-untyped-calls%2Cdisallow-untyped-decorators%2Cdisallow-untyped-defs%2Cwarn-incomplete-stub%2Cwarn-redundant-casts%2Cwarn-return-any%2Cwarn-unreachable%2Cwarn-unused-configs%2Cwarn-unused-ignores&gist=9604ab8dfb68e31788348b8ea36b54a1

@KotlinIsland KotlinIsland added the bug mypy got something wrong label Sep 13, 2021
@DetachHead
Copy link
Contributor

Also c2 = tuple[int, ...] shows an incorrect error

@Akuli
Copy link
Contributor

Akuli commented Jan 13, 2022

Still happening with mypy 0.931 in .pyi files:

(env) akuli@akuli-desktop:~/typeshed$ cat a.pyi
_Color = str | tuple[float, float, float]

(env) akuli@akuli-desktop:~/typeshed$ mypy a.pyi
a.pyi:1: error: Type application has too many types (1 expected)
Found 1 error in 1 file (checked 1 source file)

Could potentially be fixed by #11915. This too is a blocker for using new union syntax everywhere in typeshed.

@AlexWaygood
Copy link
Member

Yeah, looks like it could be fixed by #11915. I now have a minimal repro for the case that motivated that one, but I'm still working on incorporating the repro into mypy's test suite.

I'll try to test whether my proposed stub-only fix also fixes this case, and add a regression test for it, if so.

@AlexWaygood
Copy link
Member

Could potentially be fixed by #11915. This too is a blocker for using new union syntax everywhere in typeshed.

I have just tested this, and it appears that this is not fixed by #11915, sadly. (@sobolevn, @hauntsaninja, any idea about what the cause of this might be?)

@AlexWaygood
Copy link
Member

Here is a failing test that is ready to be integrated into mypy's test suite, if it is helpful:

[case test604TypeAliasWithParameterisedTuple]
# flags: --python-version 3.10
from color import c  # N: Revealed type is "Union[builtins.str, Tuple[builtins.float, builtins.float, builtins.float]]"
reveal_type(c)
[file color.py]
_Color = str | tuple[float, float, float]
c: _Color
[builtins fixtures/tuple.pyi]

This fails with:

Expected:
  main:2: note: Revealed type is "Union[builtins.str, Tuple[builtins.float, builtins.float, builtins.float]]" (diff)
Actual:
  tmp/color.pyi:1: error: Type application has too many types (1 expected) (diff)
  main:3: note: Revealed type is "Union[builtins.str, Tuple[builtins.float, builtins.float, builtins.float]]" (diff)

Alignment of first line difference:
  E: main:2: note: Revealed type is "Union[builtins.str, Tuple[builtins.float...
  A: tmp/color.pyi:1: error: Type application has too many types (1 expected)...
     ^

So mypy appears able to infer the type just fine, but nonetheless raises the spurious "Type application has too many types" error message.

@hauntsaninja
Copy link
Collaborator

Error is happening in a different, later place of the type checker. Quickest fix is probably special casing tuple in checkexpr's visit_type_application

@KotlinIsland
Copy link
Contributor Author

Here is a failing test that is ready to be integrated into mypy's test suite

Whats the deal with contributing xfail tests?

I could add a whole heap from issues I've raised, is that useful at all?

@hauntsaninja
Copy link
Collaborator

(just speaking for myself) I think of them as basically a better TODO comment.
E.g., I wouldn't typically write a PR that just adds a TODO, but if I added a PR that fixed some things but left some stuff unresolved or regressed in a minor way I'd leave a TODO. The other use case for xfails I see is if it's in a finnicky part of the type checker where it could be "accidentally" fixed and you'd want to know if so.

@KotlinIsland
Copy link
Contributor Author

So if I made some PRs, only adding xfails from issues I've raised, they would be appreciated?

@AlexWaygood
Copy link
Member

To be clear, I wasn't suggesting that the test case I was providing above should be integrated into the test suite now, without a fix for the issue; I just thought it might be helpful to someone else, if they wanted to work on a fix. The mypy test suite is a slightly different environment to running mypy normally, so it's not always as easy to reproduce something in the test suite as it is in mypy playground.

@JelleZijlstra
Copy link
Member

I haven't really looked into this, but I imagine xfail tests are prone to failing for the wrong reason. We frequently make big changes to our test suite when some wording changes a little, so chances are xfail tests will rapidly start failing not because of the actual bug but because the test says "builtins.int" instead of "int".

@sobolevn
Copy link
Member

sobolevn commented Feb 6, 2022

I've submitted #12134
Please, feel free to review! 👍

@KotlinIsland KotlinIsland changed the title false positive "error: Type application has too many types (1 expected)" on tuple when annotated as a type (🐞) False positive "error: Type application has too many types (1 expected)" on tuple when annotated as a type or in a new union syntax (PEP 406) Jun 29, 2022
@AlexWaygood
Copy link
Member

@KotlinIsland you changed the title of this issue yesterday but the title now refers to the wrong PEP. You want 604, not 406.

@KotlinIsland KotlinIsland changed the title (🐞) False positive "error: Type application has too many types (1 expected)" on tuple when annotated as a type or in a new union syntax (PEP 406) (🐞) False positive "error: Type application has too many types (1 expected)" on tuple when annotated as a type or in a TypeAlias with new union syntax (PEP 604) Jun 30, 2022
JukkaL added a commit that referenced this issue Nov 25, 2022
Fix type aliases like these:
```
T = tuple[int, str]
```
Type applications involving fixed-length tuples still don't fully work.
The inferred type is a variable-length tuple when constructing a tuple
using a type application, e.g. `tuple[int, str]((1, ""))`. This seems a
pretty low-priority issue, whereas the type alias use case seems common.

Most of the work was by @sobolevn originally in #12134. I just finished
it up.

Fixes #11098.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects-typeshed Anything that blocks a typeshed change bug mypy got something wrong priority-0-high topic-pep-585 PEP 585 (builtin generics) topic-pep-604 PEP 604 (union | operator) topic-type-alias TypeAlias and other type alias issues
Projects
None yet
7 participants