Thanks also Kevin for this feedback! Good point about being careful to distinguish type parameters vs type arguments. If I understand correctly, you're making two points:
1. The wording of the 'Multiple Type Variable Tuples: Not Allowed' section - you're saying that we're being a bit imprecise here in saying that we disallow multiple TypeVarTuples in a type parameter list, given that in e.g. `def f(x: *Ts1, y: *Ts2)`, both Ts1 and Ts2 are members of the parameter list for the function f, but there it's unambiguous, so in fact it *is* allowed. 2. Use of wrong terminology elsewhere in the PEP. Agreed. I'll draft a PR tweaking the wording to fix both these points. On Thu, 13 Jan 2022 at 11:28, Kevin Millikin <kmilli...@deepmind.com> wrote: > The wording there probably should be improved. I had a different > interpretation when I read that, so that suggests it needs to be clarified. > > We should ensure to draw a clear distinction between type parameters and > type arguments. (Generic classes and functions are parameterized over type > parameters and they have a type parameter list that is implicit in the > syntax. Generic classes can be explicitly instantiated by giving them type > arguments, and an instantiation has a (explicit or implicit) type argument > list.) > > So when I read: > > """ > As of this PEP, only a single type variable tuple may appear in a type > parameter list: > > class Array(Generic[*Ts1, *Ts2]): ... # Error\ > """ > > I interpreted it to mean that the error is that the type _parameters_ of > the generic class Array include *Ts1 and *Ts2 (not that they were used as > type arguments to Generic). Similarly, this should be an error: > > class Array(dict[*Ts1], Generator[*Ts2]): ... > > even though there is only a single type variable tuple appearing in a type > _argument_ list. > > The reason for the restriction is that the tupling of Array's type > arguments is not explicit in an instantiation of Array, so we rely on this > restriction so that they can be unambiguously tupled. > > I don't think there is necessarily a similar restriction on a generic > function's type parameters, because we don't have the ability to explicitly > instantiate generic functions anyway. > > An alternative wording is along the lines of: "As of this PEP, only a > single type variable tuple may appear among a generic class's type > parameters." > > def foo(*args: tuple[*Ts1, *Ts2]) -> ... > > is already prohibited by "Multiple Unpackings in a Tuple: Not Allowed". > > There are three other occurrences of "type parameter list" in the PEP. > Two of them talk about instantiating generic type aliases and should be > changed to "type argument list". The last one is less clear, I can't quite > parse out what it's trying to say. > > On Wed, Jan 12, 2022 at 5:04 PM Guido van Rossum <gu...@python.org> wrote: > >> On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin <pvikt...@redhat.com> >> wrote: >> >>> Matthew Rahtz wrote: >>> > Hi everyone, >>> > >>> > We've got to the stage now with PEP 646 that we're feeling pretty happy >>> > with it. So far though we've mainly been workshopping it in >>> typing-sig, so >>> > as PEP 1 requires we're asking for some feedback here too before >>> submitting >>> > it to the steering council. >>> > >>> > If you have time over the next couple of weeks, please take a look at >>> the >>> > current draft and let us know your thoughts: >>> > https://www.python.org/dev/peps/pep-0646/ (Note that the final couple >>> of >>> > sections are out of date; https://github.com/python/peps/pull/1880 >>> > clarifies which grammar changes would be required, now that PEP 637 has >>> > been rejected. We also have a second PR in progress at >>> > https://github.com/python/peps/pull/1881 clarifying some of the >>> motivation.) >>> > >>> > Thanks! >>> > Matthew and Pradeep >>> >>> Hi, >>> I'm very late to the discussion -- I relied on the typing-sig and SC to >>> handle this, but now that I'm on the SC, I no longer have that luxury :) >>> This mail has my own opinions, not necessarily the SC's. >>> >>> >>> I've read the PEP, and I quite like it! It's clear that typing-sig >>> thought this through very well. >>> The thing that surprised me is the proposed changes that affect more >>> than typing annotations. Quite deep in the PEP, the "Grammar Changes" >>> section explains the (quite exciting) change to make star-unpacking >>> possible in normal indexing operations, e.g.:: >>> >>> idxs_to_select = (1, 2) >>> array[0, *idxs_to_select, -1] # Equivalent to [0, 1, 2, -1] >>> >>> However, the PEP is silent about indexing assignment, e.g.:: >>> >>> array[0, *idxs_to_select, -1] = 1 >>> >>> IMO, it would be very confusing to not keep these in sync. If they are, >>> the assignment change should be documented and tested appropriately. Is >>> that the plan? >>> >> >> The previous SC approved the PEP despite this. >> >> If you want to convince the SC to request this feature parity in the PEP, >> I won't stop you. >> >> But unless that happens I would rather not update the PEP again (it's >> been tough to get to this point). >> >> Maybe you can write a separate PEP? That would probably be simpler for >> all involved (the PEP 646 authors would not have to be involved, and the >> separate PEP would be very straightforward. >> >> >>> For a second point, the PEP says: >>> >>> > this PEP disallows multiple unpacked TypeVarTuples within a single >>> type parameter list. This requirement would therefore need to be >>> implemented in type checking tools themselves rather than at the syntax >>> level. >>> >>> Typing annotations are sometimes used for other things than *static* >>> typing, and I wouldn't be surprised if type checkers themselves started >>> allowing this (as a non-standard extension in cases where things aren't >>> ambiguous): >>> >>> def tprod(Generic[*T1], Generic[*T2]) -> Generic[*T1, *T2]: ... >>> >> >> I don't think that sentence is trying to forbid this. The problem appears >> in things like >> >> def foo(*args: tuple[*Ts1, *Ts2]) -> ... >> >> Maybe the wording in the PEP can be imrpoved? >> >> >>> If multiple unpackings in a tuple aren't blocked by the compiler, they >>> should be tested and documented as syntactically valid annotations -- >>> just not valid static typing annotations (even though other uses are >>> currently deprecated). In particular, once the compiler allows multiple >>> unpackings, disallowing them at the syntax level later would mean >>> breaking backwards compatibility. >>> Do we share that view? >>> >> >> Agreed that the syntax with multiple stars will not be deprecated at >> runtime, but type checkers may reject it. (Just as type checkers reject >> many other programs that would run fine.) >> >> >>> And after reading the PEP again, I'm unclear on some details in the >>> Aliases section. Could you please clarify these examples for me? >>> >>> SplitDataset = Tuple[Array[*Ts], Array[*Ts]] >>> SplitDataset[Height] # Valid? What would this be equivalent to? >>> >>> >>> TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]] >>> TwoArrays[Height] # Valid? Equivalent to what? How to specify this >>> fully? >>> >> >> I'll leave this to the PEP authors to address. >> >> -- >> --Guido van Rossum (python.org/~guido) >> *Pronouns: he/him **(why is my pronoun here?)* >> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >> _______________________________________________ >> 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/ZHBIGZQPK6Y5MSAOV3BHU4VRPIUKSJHJ/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >
_______________________________________________ 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/47SKCKPYGTP74Y6TRNL4HXJPVW2LGXUX/ Code of Conduct: http://python.org/psf/codeofconduct/
