Lenient TypeVarTuple checking when number of dimensions is unknown

Currently this generates an error:

from typing import Any

class C[*Ts, S]:
    pass

a = C[int, str]()
a = C[*tuple[Any, ...], str]()  # Error

This is the output:

error: Incompatible types in assignment (expression has type "C[*tuple[Any, ...], str]", variable has type "C[int, str]")

However, this doesn't generate an error:

from typing import Any

class C[*Ts, S]:
    pass

a = C[int, str]()
a = C[*tuple[Any, ...]]()  # No error

I'd argue that the first example shouldn't generate an error either. One possible rule would be to allow this as long as some substitution of the *tuple[Any, ...] part would match the target type.

We could possibly also generalize the matching of unknown-length TypeVarTuple type arguments when the unknown-length part has a non-Any tuple item type. This could reduce apparent false positives. Example:

from typing import Any

class C[*Ts, S]:
    pass

a = C[int, int]()
a = C[*tuple[int, ...]]()  # No error?

This would only change the behavior of variadic generics. Variable-length tuples would continue to behave as they behave currently, i.e. tuple[int, ...] wouldn't be assignable to tuple[int, int]. The tuple behavior has been around for a very long time, so it doesn't make sense to change it, but variadic generics are a relatively new and untested feature.

The primary motivation is help with NumPy and libraries that provide multidimensional array-like types.

Proper subtype checks should continue to work as they work currently, since we can't safely simplify say C[int] | C[*tuple[Any, ...]].

cc @ilevkivskyi who I chatted about this recently

Inizia eseguendo con mypy i due esempi di TypeVarTuple dell’issue e confronta le diagnosi attuali. Analizza i percorsi di compatibilità dei variadic generics e di verifica dei sottotipi, quindi aggiungi la copertura per i casi proposti di lunghezza sconosciuta con Any e non-Any, preservando il comportamento esistente delle tuple di lunghezza variabile.