Do we need to add invariant tuple matching to the spec?

[davidhalter]

I'm trying to figure out how to implement invariant tuple[int, ...] ≡ tuple[int, int] matching. Pyright and Mypy disagree and IMO it's a prime candidate to add to the spec (I'm not 100% sure this is not specified, but it feels like it). I like Mypy better here, but would be happy if this was added to the spec either way.

Am I missing something? Which direction should we take? I discovered this problem with type var tuples, where this can also cause issues when matching for example X[Unpack[Tuple[int, ...]]] ≡ X[int, int]. I personally think it's very annoying for library authors if type checkers do this in a different way. Also note that there's a different between invariant matching of tuple[int, ...] and tuple[Any, ...] in Mypy.

from typing import *
def g(
    x: list[list[tuple[int, ...]]],
    y: list[list[tuple[Any, ...]]],
    z: list[tuple[int, int]],
):
    x[0] = z
    y[0] = z

Mypy:

main.py:7: error: Incompatible types in assignment (expression has type "list[tuple[int, int]]", target has type "list[tuple[int, ...]]")  [assignment]
Found 1 error in 1 file (checked 1 source file)

Pyright: No issues

[hauntsaninja]

I might be misunderstanding, but I think the behaviour here follows from the specification in https://typing.python.org/en/latest/spec/tuples.html#type-compatibility-rules and that mypy, ty, pyrefly get this right and pyright gets it wrong

[carljm]

I think this is already clearly specified at https://typing.python.org/en/latest/spec/tuples.html#tuple-type-form

This just looks like a pyright bug to me, I don't think any new specification is needed.

def bare(x: tuple[int, int], y: tuple[int, ...]):
    x = y  # everyone agrees this is an error
    y = x  # everyone agrees this is not an error
    
def in_list(x: list[tuple[int, int]], y: list[tuple[int, ...]]):
    x = y  # everyone agrees this is an error
    y = x  # everyone but pyright agrees this is an error

("everyone" above means "mypy/pyright/ty/pyrefly/zuban")

The fact that either of lines 2 or 3 is an error (meaning the two tuple types are not equivalent, or even mutually assignable gradual types) is sufficient to say definitely that both lines 6 and 7 must be an error, due to invariance of list.

[davidhalter]

Thanks, sorry for missing that part of the spec.

Does this imply that TypeVarTuples should follow the same route? Because that would make Mypy wrong here:

from typing import *

Ts = TypeVarTuple("Ts")
class B(Generic[Unpack[Ts]]): ...

def fiv(x: B[Unpack[Tuple[int, ...]]]) -> None: ...

cii: B[int, int]
fiv(cii)

Mypy shows no issues, but it should I guess since TypeVarTuples are invariant? (playground)

[carljm]

Yes, I think mypy and pyright are both getting that wrong -- as long as TypeVarTuple is required to be invariant, that should be an error. Pyrefly and pycroscope both error there, I think correctly, saying that B[int, int] is not assignable to B[*tuple[int, ...]].

Maybe we've had less pressure to support covariance for TypeVarTuple because mypy and pyright both fail to actually implement its invariance 😆