Yes, exactly. Specifically, the "wrong" example in section 'Multiple Type Variable Tuples: Not Allowed' suggests that maybe what is wrong is that `Generic` was given more than one unpacked type variable tuple. The actual problem is a consequence of that: `class Array` has more than one type variable tuple as type parameters. (But there are other ways that could happen and all of them should be wrong.)
I think it might be good to say that explicitly in that section. On Thu, Jan 13, 2022 at 4:18 PM Matthew Rahtz <mra...@google.com> wrote: > 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/2IAEW265F5FM6HW57EJBF5GATRFZ45QK/ Code of Conduct: http://python.org/psf/codeofconduct/
