gh-87390: Add tests demonstrating current type variable substitution behaviour

[mrahtz]

Here's a reference of what we currently do and don't allow in terms of type variable substitution in aliases. I've marked the cases that I think the current implementation is incorrect on.

Ideally I'd like to merge this as-is, even with the test cases whose expected results aren't what we think they should be - I think it'll make our job implementing the remaining fixes easier if we can just twiddle one line of an existing test case rather than having to remember to copy-paste the test case that each change fixes.

Some cases I'm unsure about are:

• tuple[T][*tuple[int, ...]]. My understanding is that when it comes to tuple[int, ...], the current behaviour of type checkers is to "Try to find a way to make it work" - I think this should be tuple[int]?
• class C(Generic[T1, T2]): ...; C[*tuple[int, ...], *tuple[str, ...]]. By similar reasoning, this should work - but should it be C[int, int], C[int, str], or C[str, str]?

@pradeep90 What do you think?

https://bugs.python.org/issue47006

[JelleZijlstra]

Thanks, this is a really helpful list.

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[mrahtz]

Re @JelleZijlstra's suggestion (if I understood right?) to leave unpacked tuples unsimplified across the board: I just realised this means we might have to ease up on checks for the right number of arguments across the board.

For example:

tuple[T1, T2][*tuple[int, str]]

This should be valid, but I think at the moment it would trigger a TypeError, because it looks like we're passing only a single argument *tuple[int, str] to an alias that expects two arguments.

I guess easing up on type argument number checks should be fine though? The alternative would be to have some fancy logic that tries to detect how many type arguments something like *tuple[int, str] actually counts for, but that seems like it could get messy.

[mrahtz]

Actually, having thought about it more over the past few days, I don't think leaving unpacked tuples unsimplified in all case will work. For example, if we did:

Alias = tuple[T1, bool, T2]
Alias[*tuple[int, str]]  # Should be tuple[int, bool, str]

There's no way we could properly evaluate the result of that unless we did unpack *tuple[int, str]. I've added another test case for this scenario.

Having said that, Jelle, I'm still bearing in mind your comment:

'generic[T]', '[*tuple_type[int, ...]]', 'generic[*tuple_type[int, ...]]' # Should be generic[int]?

I'd rather leave this as is. If we simplify it, we make it impossible for runtime introspection to even tell the difference.

I do agree that for the particular case of *tuple[int, ...] we should leave it unsimplified. I think the only alias involving *tuple[int, ...] that should be valid at runtime for now is generic[*Ts][*tuple[int, ...]].

I'll update the tests accordingly.

[pradeep90]

(Damn, GitHub doesn't make it obvious at all whether you've submitted a review or not. I thought I'd submitted this days ago.)

[pradeep90]

For what it's worth, there won't be an observable difference from the type checking point of view. For example, if someone tries to pass in this instantiated alias C[*tuple[int, ...]] to a function that expects C[A, *Rs], they will still get A=int, Rs=tuple[int, ...].

So, we have some freedom in what to do here. If getting C[int, *tuple[int, ...]] is hard, it might be ok to keep C[*tuple[int, ...]]

[mrahtz]

I think this is a case I updated since your review. The vibe I'm getting from @JelleZijlstra is that the kind of logic complexity he'd be happy with (correct me if I'm wrong, @JelleZijlstra) wouldn't be up to dealing with C[T, *Ts][*tuple[int, ...]] - either figuring out the 'right' answer of C[int, *tuple[int, ...]], or accepting it as valid and giving the mostly-right answer of C[*tuple[int, ...]].

[mrahtz]

In fact, according to the updated tentative spec at #91162, we'd disallow this altogether - we wouldn't allow any cases where *tuple[int, ...] has to be split among multiple things.

[JelleZijlstra]

I came across a case in the typing-extensions tests that is not covered here yet:

from typing import *
Ts = TypeVarTuple('Ts')
T1 = TypeVar('T')
T2 = TypeVar('T')
class C(Generic[T1, T2, Unpack[Ts]]): pass
with self.assertRaises(TypeError):
    C[int]

typing.py currently accepts this without errors.

[mrahtz]

[@JelleZijlstra]

I came across a case in the typing-extensions tests that is not covered here yet:

from typing import *
Ts = TypeVarTuple('Ts')
T1 = TypeVar('T')
T2 = TypeVar('T')
class C(Generic[T1, T2, Unpack[Ts]]): pass
with self.assertRaises(TypeError):
    C[int]

typing.py currently accepts this without errors.

For the time being, this intentional - we decided not to check arity at runtime for variadics (https://github.com/python/cpython/blob/main/Lib/typing.py#L1331).

[JelleZijlstra]

Going to merge this now so we have the test framework. We'll likely adjust some of the cases though.