On 13. 01. 22 16:23, Matthew Rahtz wrote:
Thanks for this feedback, Petr!
*First point (indexing assignment)*
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.
Thanks.
*Second point (multiple TypeVarTuples)*
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?
Even less, actually. The PEP doesn't make a very clear distinction between invalid Python syntax vs. invalid type annotation, so I wanted to check if we're on the same page here: the newly valid syntax will be subject to PEP 387. We clearly are on the same page, and I don't think you need to update the PEP.
*Third point (aliases)* * * 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 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.
When I asked my curious question, I thought I misread a piece of text, not that it's a detail that went unnoticed, and could delay the PEP. I can't speak for the whole SC, but on the Monday meeting I'll suggest accepting the PEP with a note that - index assignment is also affected, and - the details around multiple unpackings in a type expression aren't specified precisely. This gives individual type checkers some leeway, but can be tightened in future PEPs.