(🐞) 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)

[KotlinIsland]

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

[DetachHead]

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

[Akuli]

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]

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]

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]

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]

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]

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]

(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]

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

[AlexWaygood]

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]

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]

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

[AlexWaygood]

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