On Tue, 19 Jan 2021 at 13:51, gohanpra@gmail.com wrote:

Hello,

This is a great PEP. It turns out to be applicable in a variety of scenarios.

Case in point: Matthew Rahtz and I are working on PEP 646: Variadic Generics (https://www.python.org/dev/peps/pep-0646/; discussion on typing-sig). It is a type system feature that allows specifying an arbitrary tuple of type variables instead of a single type variable.

We plan to use your proposed syntax to represent unpacking a tuple type. This would be analogous to `*` for unpacking a tuple value:

• `Tensor[int, *Ts, str]` and `Tensor[*Ts1, *Ts2]`
• such variadic classes would be declared as `class Tensor(Generic[T, *Ts, T2]):`

Questions:

1. Does PEP 637 support unpacking multiple `*` arguments?
   • e.g., Tensor[int, *Ts, str, *Ts2]

Yes, technically yes, and it does in our experimental branch.

_but_

Brandt and I are unsure about the semantics of it, specifically the corner case of star unpacking a tuple with one element. The current PEP says that the following two are equivalent:

a[1] and a[*(1,)]. (calls __getitem__ with index = 1)

However, the way it's implemented now, these two are equivalent

a[1,] and a[*(1,)] (calls __getitem__ with index = (1,))

I think we would both love a discussion over it.

2. Does PEP 637 allow a positional argument after a `*`?
   • e.g., Generic[T, *Ts, T2]

Yes.

PEP 637 says "Sequence unpacking is allowed inside subscripts", so it looks like these should be allowed (just as in function calls). But I wanted to confirm it explicitly since this is our core use case and there was no example with multiple sequences being unpacked.

They are.

3. We also wanted to ask - how's your implementation going?

It's ready, but not reviewed, and not matching the PEP for the point above.

https://github.com/stefanoborini/cpython/tree/PEP-637-implementation-attempt...

I'll update against master tonight.

We'll be starting implementation in typing.py soon. Since there's some overlap we wanted to make sure we're not duplicating your work, and that there won't be any merge conflicts later. Do you have a fork we might be able to get early access to? We're also targeting the 3.10 release for our implementation.

Contact me directly if you have any issues with it.

Guido van Rossum wrote:

Honestly I think it's fine the way you have implemented it -- since there is a difference between a[1] and a[1,], a[*t] where len(t) == 1 has to make a choice, and it's fine if this always passes a tuple.

Yup, I agree. Not only because it feels more intuitive to me (which is probably why I thoughtlessly implemented the parser this way before Stefano pointed out to me that it contradicted the PEP), but also because it's much simpler to reason about and understand. We don't have to worry about the type of the index varying at runtime based on the length of the unpacked args (empty tuple vs single object vs two-or-more-element tuple). I'm pretty sure that's a big win for static analysis, and I *know* it's a big win for simplifying the implementation.

The "rule" for this is simple. If there's a star-unpacking in the positional arguments, it will always pass a tuple, regardless of the resulting length.

Brandt