*First point (indexing assignment)*
[Guido]
> Agreed. I just misremembered this, my bad! Please do the clarification
etc.
Will do.
*Second point (multiple TypeVarTuples)*
[Guido]
> I would love it for the cases where it's *not* ambiguous to just work
(once type checkers support it). I'd like the PEP to be written so as not
to disallow those. Type checkers that only support a single star even when
it's unambiguous should be considered out of compliance. (But could still
be fully compliant otherwise.) User pressure will then sort things out.
That seems better than requiring a follow-up PEP just to allow
non-ambiguous cases that follow the PEP's semantics.
I agree that would be nice, but I feel a bit worried this could result in
additional churn.
I was going to propose adding just a single sentence to the PEP along the
lines of "Multiple unpacking are ok when the result would be unambiguous",
but as you point out, there's no simple rule for deciding what would and
wouldn't be ambiguous - so we'd probably have to spell out it out with
examples in the PEP, which would a) make the PEP even longer, and b) maybe
put us at risk of the SC wanting to re-re-review.
So overall I'd strongly prefer to just add a sentence clarifying support at
the grammar level to satisfy Petr, but leave it at that. Wdyt?
To be clear, though:
> This should clearly be disallowed:
> def f(*args: *tuple[*Ts1, *Ts2])...
> This (and similar variants) should also be disallowed:
> def f(*args: *tuple[*Ts, *Ts])...
> This should be allowed:
> def f(*args: *tuple[int, *Ts, str, T])...
> But not this:
> def f(*args: *tuple[*Ts1, str, *Ts2])...
Right, I think the current wording in the PEP ("Multiple Unpackings in a
Tuple: Not Allowed") is sufficient to make it clear these are disallowed.
> It seems you are saying that this would be disallowed, even though
there's no ambiguity?
> def f(a: Array[*Ts1], b: Array[*Ts2])...
This should definitely be fine, and I don't think there's any wording in
the PEP which would suggest they be disallowed.
*Third point (aliases)*
[Guido]
> As a corollary, this would also be correct, right?
> SplitDataSet[Height, Width]
> and it would make Ts be (Height, Width). Right?
Right, exactly.
> TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]]
> TwoArrays[Height]
> Given the previous example and my corollary, this seems ambiguous, just
like `def f(*tuple[*Ts1, *Ts2])`.
Oh, right, good point. So it sounds like the algorithm I described for
aliases isn't *quite* accurate - it's not that we assign types to type
variables by going from left to right and assigning greedily, it's that we
assign types to type variables using the same mechanisms as in other
contexts.
So I guess the result is that multiple TypeVarTuples in aliases should be
disallowed, for the same reasons as disallowing multiple TypeVarTuples in
parameter lists elsewhere? (I'll wait for confirmation on this from you and
Pradeep, then draft a PR clarifying this.)
On Thu, 13 Jan 2022 at 16:44, Kevin Millikin <kmilli...@deepmind.com> wrote:
> 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/7NEPZBCJUXG2AC32HDUOF52FEI7GAJGY/
Code of Conduct: http://python.org/psf/codeofconduct/
