[Python-Dev] PEP 646 (Variadic Generics): final call for comments

[Matthew Rahtz via Python-Dev]

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
___
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/5GWS2GGVJ4PAMOWM6YVVKZVMR5BRFRGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Asking for clarifications in PEP 646 and postponing to Python 3.11

[Matthew Rahtz via Python-Dev]

Thanks for the feedback, Brett! This is a very reasonable response given
the implications of a syntax change. We'll work on a more thorough
implementation and add details to the PEP of the grammar changes that are
necessary, and see you again in the cycle for Python 3.11.

On Fri, 23 Apr 2021 at 20:16, Brett Cannon  wrote:

> First, the SC is postponing considering accepting
> https://www.python.org/dev/peps/pep-0646/ any further until Python 3.11.
> There's unfortunately not enough time before b1 to get requested updates
> into the PEP, discuss the PEP again, approve it, and then review an
> implementation thoroughly.
>
> Second, this PEP is proposing new syntax for Python but that detail is
> barely touched upon. For instance, there isn't a direct proposal of what
> grammar changes that should be made. There's also no discussion of what the
> exact runtime semantics should be. While a lot could be inferred by "it's
> allowing * within indexing contexts" (which is basically what the PEP is
> proposing from a syntactic perspective), that isn't a spec. 😉 As such, we
> are asking that the PEP be expanded upon to fully explain the proposed
> syntactic change, it's impact on the language and it's spec, etc.
>
> Once this update happens, we will be happy to look at the PEP again for
> consideration of inclusion in Python 3.11.
>
>
> -Brett (on behalf of the SC)
>
___
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/J3YYZ4PB5HZQSKGDZCKPTNPKDPBUETOB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

[Matthew Rahtz via Python-Dev]

Still working on it :) Specifically the grammar changes in cpython, though
I haven't found much time to work on it recently. Tune into the tensor
typing meeting on Monday for a more detailed update.

On Thu, 8 Jul 2021 at 19:49, Filipe Laíns  wrote:

> On Sat, 2021-03-20 at 14:08 +, Matthew Rahtz via Python-Dev 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
>
> Hey,
>
> Any updates on this? I am very excited about this PEP :)
>
> Cheers,
> Filipe Laíns
>
___
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/ILYBYAWJR6TREUZBSU5SERI46JQC4SYV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP-646 question: unpacking into single Generic parameter

[Matthew Rahtz via Python-Dev]

Oops, sorry for the slow reply - I'm not subscribed to this mailing list.

As Mehdi2277 says, this would indeed require the Map operator we'll introduce 
in a future PEP.

But that's a good point about the `*Tuple[int, Ts]` syntax. I think the 
interpretation of it that would be most consistent with the rest of PEP 646 
would actually be something slightly different than you had in mind - instead 
of saying that the Callable took args like

Tuple[int, Ts[0]], Tuple[int, Ts[1]], ...

it would say that the Callable took a variable number of arguments, the first 
of which was `int`, and the rest of which are bound to `Ts`. And this is indeed 
something we haven't talked about explicitly how to specify yet.

Most of the discussion of PEP 646 has taken place on typing-sig, so I'll start 
a new thread there to discuss this.
___
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/PZYE2XNNOF3WCU4DXSLYFKOXDZW6WNJA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics

[Matthew Rahtz via Python-Dev]

Hi Barry,

Absolutely fantastic - thank you for letting us know! As Guido says,
there's one final thing that we thought would be easy to resolve but has
actually turned out to be a little tricky. Happy to proceed as you think is
best here.

Matthew

On Wed, 17 Nov 2021 at 22:33, Guido van Rossum  wrote:

> Hi Barry,
>
> That's fantastic news!
>
> Somewhat embarrassingly, on typing-sig we're still discussing one or two
> final tweaks. In particular, the PEP as accepted forbids a certain
> construct (passing a tuple of indefinite length to a function using `*args:
> *Ts`) that after all we may actually want to allow. This would affect
> static type checkers only, there's no change in the grammar or runtime
> associated with lifting this restriction. See
> https://github.com/python/peps/pull/2125
>
> I presume the SC is okay with that?
>
> --Guido
>
> On Wed, Nov 17, 2021 at 2:15 PM Barry Warsaw  wrote:
>
>> Hello Mark, Matthew, Pradeep, Vincent, and Guido,
>>
>> The Python Steering Council discussed the latest version of PEP 646
>> (Variadic Generics) at our last meeting, and have unanimously decided to
>> accept the PEP.  Congratulations!
>>
>> We want to specifically mention that we appreciate the way you called out
>> the Python grammar changes required by the typing features you proposed.
>> As we’ve said before, the Steering Council strongly believes that the
>> typing language and the “general” Python programming language should remain
>> aligned, so the implications of syntax change proposed in the PEP for
>> typing needed to be addressed for non-typed Python as well.  The PEP
>> explains this change well, and does a good job of justifying the semantics
>> and usefulness of the change for non-type related purposes.
>>
>> Please feel free to change the PEP status to Accepted, and to merge your
>> changes to Python 3.11 at your convenience.
>>
>> With our appreciation,
>> -Barry (on behalf of the Python Steering Council)
>>
>>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>
___
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/2HNXWLHXRRJGP75SN2W7RHM2TIJVKWL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics

[Matthew Rahtz via Python-Dev]

Thanks, Brett. We'll notify you once we've resolved the issue.

On Thu, 18 Nov 2021 at 19:30, Brett Cannon  wrote:

> I put the PEP back on our agenda to discuss this.
>
> On Wed, Nov 17, 2021 at 2:40 PM Guido van Rossum  wrote:
>
>> Hi Barry,
>>
>> That's fantastic news!
>>
>> Somewhat embarrassingly, on typing-sig we're still discussing one or two
>> final tweaks. In particular, the PEP as accepted forbids a certain
>> construct (passing a tuple of indefinite length to a function using `*args:
>> *Ts`) that after all we may actually want to allow. This would affect
>> static type checkers only, there's no change in the grammar or runtime
>> associated with lifting this restriction. See
>> https://github.com/python/peps/pull/2125
>>
>> I presume the SC is okay with that?
>>
>> --Guido
>>
>> On Wed, Nov 17, 2021 at 2:15 PM Barry Warsaw  wrote:
>>
>>> Hello Mark, Matthew, Pradeep, Vincent, and Guido,
>>>
>>> The Python Steering Council discussed the latest version of PEP 646
>>> (Variadic Generics) at our last meeting, and have unanimously decided to
>>> accept the PEP.  Congratulations!
>>>
>>> We want to specifically mention that we appreciate the way you called
>>> out the Python grammar changes required by the typing features you
>>> proposed.  As we’ve said before, the Steering Council strongly believes
>>> that the typing language and the “general” Python programming language
>>> should remain aligned, so the implications of syntax change proposed in the
>>> PEP for typing needed to be addressed for non-typed Python as well.  The
>>> PEP explains this change well, and does a good job of justifying the
>>> semantics and usefulness of the change for non-type related purposes.
>>>
>>> Please feel free to change the PEP status to Accepted, and to merge your
>>> changes to Python 3.11 at your convenience.
>>>
>>> With our appreciation,
>>> -Barry (on behalf of the Python Steering Council)
>>>
>>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>> 
>> ___
>> 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/YBSS4FJ474TJ23XOUSFI5E6N7GAXB3T5/
>> 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/BW4SCUPAUO7LOXAFXY4MH6SCFUYQ6TCS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Fwd: PEP 646 (Variadic Generics): final call for comments

[Matthew Rahtz via Python-Dev]

Thanks for this feedback, Petr!

*First point (indexing assignment)*

Great catch; we hadn't thought about this. I agree it would be better to
keep these in sync.

I just tested this in our current CPython implementation, and can confirm
it looks like this already works fine. So as much as I agree with Guido in
preferring not to make too many more updates to the PEP, I guess we can
indeed just fix this with a small clarification. I'll also add some tests
for this to our CPython implementation.

*Second point (multiple TypeVarTuples)*

In terms of the wording in the PEP - Guido, our intention actually *was* to
prohibit even the straightforward cases for now. Iirc, our reasoning was
that we thought the decision boundary between "straightforward to infer
type assignment" and "nontrivial to infer type assignment" (and of course
"no unique type assignment") was tricky enough that we shouldn't complicate
the already-long PEP by trying to describe all the cases where it was and
wasn't ok.

Petr, do I understand that the crux for you is basically that we should
commit to multiple-stars at the syntax level - the main implication being
to make sure we've properly documented and tested it? I'm happy with this;
we plan to follow up with another PEP that *does* talk about when multiple
unpackings are ok anyway. I guess we should just a) clarify in the PEP that
allowing multiple unpackings in the grammar isn't accidental, and b) test
this in our CPython implementation?

*Third point (aliases)*

This is actually a great point - I had to think about this myself.

Since PEP 484 doesn't explicitly spell out how assignment of type to type
variables in generic aliases works either, I had to try some things with
mypy playground to figure out what the current rules are. I think the logic
is, if we have an alias like

Foo = tuple[T1, T1, T2]
Foo[int, str]

then we construct a list of unique type variables in the alias (here [T1,
T2]), then assign types to those variables by going left to right through
the type argument list when the alias is instantiated. Guido, can you
remember from your time with mypy whether this is correct? Pradeep, I guess
you'll also know about this?

Based on that precedent, I believe that:

SplitDataset = Tuple[Array[*Ts], Array[*Ts]]
SplitDataset[Height]  # Valid; equivalent Tuple[Array[Height],
Array[Height]]

(indeed, I just tested this with Pyre, and that matches our implementation
there)

For this one:

TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]]
TwoArrays[Height]

Since we we allow a TypeVarTuple to be bound to an *empty* list of types,
when we try to assign type arguments [Height] to the unique list of type
variables [Ts1, Ts2], I think we should end up with Ts1 containing Height
and Ts2 being empty; thus:

TwoArrays[Height]  # Valid; equivalent to Tuple[Array[Height], Array[()]]

But I actually can't get this to type check correctly in Pyre. Pradeep,
this is the test I was using:
https://gist.github.com/mrahtz/cc86c29538de1d4a80a2e8958ae71c5a Am I doing
something wrong?

Also, by that logic, in this situation *all* the type arguments would be
assigned to Ts1, and Ts2 would always end up being empty. That seems a bit
weird but...*shrug* it also seems correct.

In any case, this is definitely something we should explain better in the
PEP. I'll make a TODO for myself to write something on this once Pradeep
and Guido have confirmed whether my understanding is correct.
___
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/3TGPEF465RBVLURM75RGRRR3627PXXNF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

[Matthew Rahtz via Python-Dev]

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  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  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 upd

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

[Matthew Rahtz via Python-Dev]

[Matthew]

> 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.

[Guido]

> That looks like a syntax error. We only allow *Ts if the argument is of
the form *a. `def f(x: *Ts1)` is not allowed.
> Maybe you were thinking of `def f(x: Array[*Ts1], y: Array[*Ts2]) as the
example? That seems unambiguous since the two positional arguments are
given separately.

Sorry, yes!
___
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/3BW75IG7XINYKUNMWR35TJW2F5DGW6LQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

[Matthew Rahtz via Python-Dev]

*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  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  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 
>> 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 

[Python-Dev] Re: Fwd: PEP 646 (Variadic Generics): final call for comments

[Matthew Rahtz via Python-Dev]

> Even less, actually.
> The PEP doesn't make a very clear distinction between invalid Python
> syntax vs. invalid type annotation, so I wanted to check if we're on the
> same page here: the newly valid syntax will be subject to PEP 387.
> We clearly are on the same page, and I don't think you need to update
> the PEP.

Ok, fair enough.

> When I asked my curious question, I thought I misread a piece of text,
> not that it's a detail that went unnoticed, and could delay the PEP.
> I can't speak for the whole SC, but on the Monday meeting I'll suggest
> accepting the PEP with a note that
> - index assignment is also affected, and
> - the details around multiple unpackings in a type expression aren't
> specified precisely. This gives individual type checkers some leeway,
> but can be tightened in future PEPs.

Cool. Thanks, Petr!
___
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/VZHGKB7SKI45GFP7BI7FDTO6ENOL4NL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics

[Matthew Rahtz via Python-Dev]

Fantastic, Petr! Thanks for letting us know - and thank you once again for
your patience with our last-minute changes! We'll go ahead and mark the PEP
as accepted, and merge our CPython implementation soon.

On Wed, 19 Jan 2022 at 08:34, Petr Viktorin  wrote:

> On 17. 11. 21 23:47, Barry Warsaw wrote:
> > Hello Mark, Matthew, Pradeep, Vincent, and Guido,
> >
> > The Python Steering Council discussed the latest version of PEP 646
> (Variadic Generics) at our last meeting, and have unanimously decided to
> accept the PEP.  Congratulations!
> >
> > We want to specifically mention that we appreciate the way you called
> out the Python grammar changes required by the typing features you
> proposed.  As we’ve said before, the Steering Council strongly believes
> that the typing language and the “general” Python programming language
> should remain aligned, so the implications of syntax change proposed in the
> PEP for typing needed to be addressed for non-typed Python as well.  The
> PEP explains this change well, and does a good job of justifying the
> semantics and usefulness of the change for non-type related purposes.
> >
> > Please feel free to change the PEP status to Accepted, and to merge your
> changes to Python 3.11 at your convenience.
> >
> > With our appreciation,
> > -Barry (on behalf of the Python Steering Council)
>
>
> Hello Mark, Matthew, Pradeep, Vincent, and Guido,
>
> The 2022 Python Steering Council discussed the updated PEP 646 --
> Variadic Generics, and decided to accept the PEP again, with the
> following note:
>
>The details around multiple unpackings in a type expression aren't
>specified precisely. This gives individual type checkers some leeway,
>but can be tightened in future PEPs.
>
> Please feel free to change the PEP status to Accepted and add the note
> to it, and merge your changes to Python 3.11.
>
> As Barry mentioned previously, we appreciate justifying the changes for
> non-typed Python as well.
>
>
> Thank you for your patience as we set up the new SC, and happy typing!
> - Petr (on behalf of the Python Steering Council)
>
___
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/HSVDU4YJFOAEBS3NIE77UVEF7G34DZ7Q/
Code of Conduct: http://python.org/psf/codeofconduct/