"Unexpected '...'" reported from ellipsis in type alias, but understood anyway?

[qwertystop]

Bug Report

The type typing.Tuple[Foo, ...] is accepted as meaning "tuple of Foo, arbitrary length", but tuple[Foo, ...] is not, in the context of type aliases. It's apparently understood, but produces an error message anyway.

To Reproduce

Create a file:

from typing import Tuple

IntsA = Tuple[int, ...]
IntsB = tuple[int, ...]

def foo(inputs: tuple[int, ...]) -> IntsB:
    return inputs

Then run mypy on the file.

Actual Behavior

mypy reports: test.py:4: error: Unexpected '...'. It does not report an error on line 3 (alias defined from Tuple) or 5 (the same type provided directly as an annotation rather than an alias, and also the use of the alias which produced an error). If foo is defined as returning something that is not a tuple of integers, such as ("argle",), mypy does report that as an incompatible return value type.

Your Environment

• Mypy version used: 0.812
• Mypy command-line flags: None
• Mypy configuration options from mypy.ini (and other config files): I have not set up such configuration
• Python version used: 3.9.0
• Operating system and version: Arch Linux (linux 5.11.8-arch1-1)

[syheliel]

That's my running result with python 3.8.8 & mypy 0.820+dev.641919f9496c8c62b9f45e7ec8402162667b7a11, it reports errors where tuple[int, ...] appears

example.py:4: error: Unexpected '...'
example.py:4: error: "tuple" is not subscriptable
example.py:6: error: Unexpected '...'
example.py:6: error: "tuple" is not subscriptable, use "typing.Tuple" instead

But I'm not quite undertstanding what should be the expected behavior. Do you mean that -> IntsB should also be reported as a new error at line 6? If it hits the problem, then I change -> IntsB into tuple[int, ...] :

from typing import Tuple

IntsA = Tuple[int, ...]
IntsB = tuple[int, ...]

def foo(inputs: tuple[int, ...]) -> tuple[int, ...]:
    return inputs

Also, the same result is outputed

example.py:4: error: Unexpected '...'
example.py:4: error: "tuple" is not subscriptable
example.py:6: error: Unexpected '...'
example.py:6: error: "tuple" is not subscriptable, use "typing.Tuple" instead

[qwertystop]

Python 3.9 added the ability to subscript built-in generic types (including builtins like list, collections.abc types, and non-collection types like collections.abc.callable) to specify contents directly rather than needing a parallel type hierarchy imported from typing. Your "tuple" is not subscriptable error no longer appears in Python 3.9. See also: PEP 585.

That is, typing.Tuple[int, ...] and tuple[int, ...] now mean the exact same thing, except that the former is deprecated, and so should be treated the same by mypy.

[syheliel]

Thank you for explaination! It seems that it's truly a bug. In no_subscript_builtin_alias(name: str, propose_alt: bool = True) -> str in typeanal.py, the comment says that # This should never be called if the python_version is 3.9 or newer, so there must exists something go wrong.

[syheliel]

Currently my progress on this problem is that refers_to_class_or_function(base) in semanal.SemanticAnalyzer.visit_index_expr return different results for typing.Tuple and builtins.tuple. And that causes the different reusult for the line IntsA = Tuple[int, ...] and IntsB = tuple[int, ...]

[syheliel]

the commit 46d6c6b fix this issue, @JukkaL would you like to close the issue?

[srittau]

Related issue:

x: tuple[str, ...] 

Checking this with mypy@master (0.820+dev.1e96f1df48a6e06ba598fa8230b96671b206cba0) and Python 3.9 works fine, checking it with Python 3.8 fails: "foo.pyi:1: error: Unexpected '...'".

Adding from __future__ import annotations fixes this, but in the case of type stubs it should work in any case.

python/typeshed#5192 fails because of this.

[hauntsaninja]

Fixed on master