On Tue, 19 Jan 2021 at 13:51, <gohan...@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-2 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. -- Kind regards, Stefano Borini _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GXWMB63R763FSUJVPAJWDWO4D4X2B2XQ/ Code of Conduct: http://python.org/psf/codeofconduct/
