Great catch; we hadn't thought about this. I agree it would be better to keep these in sync.

I just tested this in our current CPython implementation, and can confirm it looks like this already works fine. So as much as I agree with Guido in preferring not to make too many more updates to the PEP, I guess we can indeed just fix this with a small clarification. I'll also add some tests for this to our CPython implementation.

In terms of the wording in the PEP - Guido, our intention actually was to prohibit even the straightforward cases for now. Iirc, our reasoning was that we thought the decision boundary between "straightforward to infer type assignment" and "nontrivial to infer type assignment" (and of course "no unique type assignment") was tricky enough that we shouldn't complicate the already-long PEP by trying to describe all the cases where it was and wasn't ok.

Petr, do I understand that the crux for you is basically that we should commit to multiple-stars at the syntax level - the main implication being to make sure we've properly documented and tested it? I'm happy with this; we plan to follow up with another PEP that does talk about when multiple unpackings are ok anyway. I guess we should just a) clarify in the PEP that allowing multiple unpackings in the grammar isn't accidental, and b) test this in our CPython implementation?

This is actually a great point - I had to think about this myself.

Since PEP 484 doesn't explicitly spell out how assignment of type to type variables in generic aliases works either, I had to try some things with mypy playground to figure out what the current rules are. I think the logic is, if we have an alias like

Foo = tuple[T1, T1, T2]

Foo[int, str]

then we construct a list of unique type variables in the alias (here [T1, T2]), then assign types to those variables by going left to right through the type argument list when the alias is instantiated. Guido, can you remember from your time with mypy whether this is correct? Pradeep, I guess you'll also know about this?

Based on that precedent, I believe that:

SplitDataset = Tuple[Array[*Ts], Array[*Ts]]

SplitDataset[Height]  # Valid; equivalent Tuple[Array[Height], Array[Height]]

(indeed, I just tested this with Pyre, and that matches our implementation there)

For this one:

TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]]
TwoArrays[Height]

Since we we allow a TypeVarTuple to be bound to an empty list of types, when we try to assign type arguments [Height] to the unique list of type variables [Ts1, Ts2], I think we should end up with Ts1 containing Height and Ts2 being empty; thus:

TwoArrays[Height]  # Valid; equivalent to Tuple[Array[Height], Array[()]]

But I actually can't get this to type check correctly in Pyre. Pradeep, this is the test I was using: https://gist.github.com/mrahtz/cc86c29538de1d4a80a2e8958ae71c5a Am I doing something wrong?

Also, by that logic, in this situation all the type arguments would be assigned to Ts1, and Ts2 would always end up being empty. That seems a bit weird but...shrug it also seems correct.

In any case, this is definitely something we should explain better in the PEP. I'll make a TODO for myself to write something on this once Pradeep and Guido have confirmed whether my understanding is correct.