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 wrote:
> On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin 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 t
