Ohh, this is interesting! tuple.__{r,}add__ methods are special-cased to handle their sizes and non-homogeneous item types. There must be something missing in fallback handling here:

@sterliakov I stepped through this example with the debugger:

from typing import assert_type

class Size(tuple[int, ...]):
    def __add__(self, other: tuple[int, ...], /) -> "Size": return Size()  # type: ignore[override]
    def __radd__(self, other: tuple[int, ...], /) -> "Size": return Size()

size: Size = Size([3,4])
tup: tuple[int, ...] = (1, 2)

assert_type(tup + size, Size)  # ✅ tuple[int, ...] + Size
assert_type(() + size, Size)  # ❌ tuple[()] + Size
assert_type((1, 2) + size, Size)  # ❌ tuple[Literal[1], Literal[2]] + Size

The last two examples fail inside this branch:

In both cases, mapped = map_instance_to_supertype(left, right.partial_fallback.type) yields tuple[int, ...] and then is_erased_instance(mapped) returns False.

That's correct: only tuple[Any, ...] is a subtype of all tuples including fixed-sizes one. tuple[int, ...] is not a subtype of tuple[int, int], for example (while the reverse is true - a fixed-size tuple[int, int] is a subtype of variadic tuple[int, ...]). This Any special-case is intentional (because variadic Any tuples can arise from some untyped constructs), but it does not generalize to other tuples. https://mypy-play.net/?mypy=master&python=3.12&flags=strict&gist=d60b71630f447223ac70c69f8b7d7d62

Sorry, I linked to the wrong place - that one is for cases without __radd__, so with custom __radd__ we fall back to plain self.check_op. Runtime dispatch doesn't care about tuple params, so we ignore __radd__ when we shouldn't. Maybe just allow variadic tuples explicitly when gathering candidates in check_op_reversible (or one more flag for is_subtype)?

Right, so it doesn't really have anything to do with tuple literals after all, I will update the OP.

@sterliakov To recapitulate:

In the specific case here, the LHS is a fixed size tuple tuple[*Ts], whereas the RHS is a variable size tuple tuple[T, ...].

So mypy checks whether is_subtype(tuple[T, ...], tuple[*Ts]); in our specific case is_subtype(tuple[int, ...], tuple[()]), which obviously fails.

However, wouldn't it make sense here to consider reinterpreting the fixed size tuple as a variable size tuple?

One could ask: Does there exist a choice of S for which tuple[*Ts] <: tuple[S, ...] and tuple[T, ...] <: tuple[S, ...]? Indeed, this is trivially true for S = object, and the minimal type that satisfies these constraints is S = T | Union[*Ts], which in our case would always be S = int, so everything checks out.

@randolf-scholz Not sure I follow, are you trying to convince me that variadic tuples should be considered subtypes of some fixed-length tuples? tuple[int, ...] might, for example, be a 3-tuple (1, 2, 3), so it cannot be a subtype of tuple[int, int] nor tuple[()]. Looking from set-oriented type theory side, no amount of upcasting and reinterpreting can make a variadic tuple subtype of a fixed tuple, the former has more elements so no bijection can exist.

By definition, tuple[T, ...] is a tuple containing zero or more elements of type T - the length is deliberately unknown. Variadic tuples are essentially sequences that happen to have class tuple, while fixed tuples are most close to product types.

If I'm not misreading, you're saying that (for some T and U) T <: U if T and U have a common supertype? That sounds wrong, consider

class A: ...
class B(A): ...
class C(A): ...

Applying your argument, does there exist a choice of S such that B <: S and C <: S? Yes, that's object and also that's A, so B <: C?

Here's a link to the spec chapter laying out tuple assignability rules: https://typing.python.org/en/latest/spec/tuples.html#type-compatibility-rules

Not sure I follow, are you trying to convince me that variadic tuples should be considered subtypes of some fixed-length tuples?

That was definitely not the goal 😅. The issue is that the is_subtype check is likely too strong to be compatible with runtime, so I was wondering if one could weaken this check - in the specific case of checking reverse-op applicability - in one way or another without breaking things.

Looking at the python C-source, the actual check performed is PyType_IsSubtype(Py_TYPE(right), Py_TYPE(left))) ¹, which simply checks whether type(right) in type(left).__mro__ ².

This check ignores generics, hence the suggestion above was to slightly weaken the is_subtype check³ to consider upcasting the parametrization of a generic type (e.g. from tuple[*Ts] to tuple[T | Union[*Ts], ...] in this case.) I do not think it ever makes sense to upcast the base type itself (e.g. from tuple to object.)

Ough, sorry, I was missing the third footnote in your previous comment - I thought you're trying to change is_subtype behaviour for all purposes.

Yes, at runtime we have essentially an issubclass check, and it really doesn't play well with static generics. Perhaps we should replace is_subtype with covers_at_runtime to determine whether __rOP__ should be called first?

@sterliakov I created a draft PR, but there are still some things unclear #19046