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.

*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?

*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 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.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3TGPEF465RBVLURM75RGRRR3627PXXNF/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to