bpo-43224: Implement substitution of unpacked TypeVarTuple

[serhiy-storchaka]

https://bugs.python.org/issue43224

[mrahtz]

I'm not sure it's sufficient to only check for the case where len(self.__parameters__) == 1 - we could have e.g.:

T1=TypeVar('T1')
T2=TypeVar('T2')
Ts=TypeVarTuple('Ts')
classA(Generic[T1, T2, Unpack[Ts]]): passB=A[int, T2, Unpack[Ts]]
C=B[str, float]
print(C)

There, B.__parameters__ is (T2, Ts), causing a TypeError later on in the code.

[serhiy-storchaka]

You are right. The previous code only worked with existing tests. New code adds tests for generics with multiple type variables.

[mrahtz]

Thanks for looking into this!

[mrahtz]

Woah, I'm not sure merging this was a good idea. We discussed this extensively in #31021 (review) and decided against implementing it this way. There are too many edge cases (e.g. the merged implementation will happily assign an unpacked arbitrary-length tuple such as *tuple[int, ...] to a plain TypeVar, which is not legal - see the extensive tests in b9b1c80#diff-04d29c98076c2d6bb75921ea9becb26a862544d39b71db87b6e354c759b9305dL794), and @JelleZijlstra suspected it might cause issues with Annotated.

I'd strongly prefer this merge to be reversed in favour of #31804 and/or further discussion on what the right approach is.

[serhiy-storchaka]

I think that list[T][int] should return list[int], and tuple[*Ts][int, str] should return tuple[int, str].

Workaround can be used in cases where this does not work.

[mrahtz]

If you're adamant about keeping this implementation, I don't feel happy about it, but I don't want this to become a blocker for us. I'll submit a new PR with extra test cases so we can be more confident we've covered the edge cases.