Clarifying specs in "Multiple Type Variable Tuples: Not Allowed"

[bzoracler]

This is related to #1439. Currently, the typing specs say:

Only a single type variable tuple may appear in a type parameter list:

class Array(Generic[*Ts1, *Ts2]): ...  # Error

In practice, this restriction seems to only apply to type parameters specified on generic types, not generic functions/methods. mypy and pyright accepts multiple TypeVarTuples in the latter, and can even solve for them indirectly:

from collections.abc import Callable

def concat_args_and_ret[*A, *R](
    f: Callable[[*A], tuple[*R]], /
#`-> tuple[*A, *R]` is rejected, but mypy and pyright can use
#`-> tuple[*A, *tuple[*R]]` to solve `R`
) -> tuple[*A, *tuple[*R]]: ...

def f(a: int, b: str, c: bytes, /) -> tuple[float, None]: ...

reveal_type(concat_args_and_ret(f))  # tuple[int, str, bytes, float, None]

The ambiguity mentioned in the specs, x: Array[int, str, bool] # Ts1 = ???, Ts2 = ???, seems to only apply when type arguments are provided to a generic type like Array (or in C++ terminology, explicit rather than deduced). The ambiguity currently does not even seem possible with functions/methods, as they can't be subscripted. So,

1. Can we still expect multiple TypeVarTuples to be allowed for generic functions/methods (def concat_args_and_ret[*A, *R]) in the future?
2. If 1. is true, can we expect some level of support for solving items like -> tuple[*A, *R] (perhaps indirectly, like -> tuple[*A, *tuple[*R]])?

[erictraut]

As you point out, the spec allows multiple TypeVarTuples to be used in a generic function/method signature. Adding a new rule that disallows this would be a breaking change, so there would need to be a really compelling reason to add such a change. I can't think of any such compelling reason, so I think it's safe to say that you can count on this continuing to work in the future.

As for your second question, there are good reasons why multiple TypeVarTuples cannot be used to parameterize a class. It creates ambiguities for a constraint solver. So I think it's unlikely that you'll see this limitation removed from the spec. There's a good reason it was added by the authors of PEP 646 when TypeVarTuple was introduced into the type system.

The type tuple[*A, *R] is equivalent to tuple[*A, *tuple[*R]], so they should behave the same under all circumstances.

[JelleZijlstra]

the spec allows multiple TypeVarTuples to be used in a generic function/method signature

The spec as quoted above says "Only a single type variable tuple may appear in a type parameter list", which would seem to include function type parameter lists. Of course, those didn't exist when PEP 646 was written, since before PEP 695 functions didn't have explicit type parameter lists. So I think we should amend that line in the spec to say it applies only to type parameter lists on classes.