[PEP 646] Allow cleanly substituting any tuple type for a TypeVarTuple #2162

pradeep90 · 2021-11-24T21:57:23Z

Our specification implicitly treated it as legal to replace a TypeVarTuple with a tuple such as Tuple[int, str]. However, we did not mention the natural implications for *args or Callable. We also did not address the behavior of unbounded tuples.

This led to artificial restrictions (such as "type variable tuples must be of known length").

This PR specifies that, wherever a Ts is used, we can legally replace it with Tuple[int, str] or Tuple[int, ...] or Tuple[int, *Ts, str]. Concretely, the following are valid:

*args: *Tuple[int, *Ts, str], etc.
Callable[[int, *Ts, str], None], etc.
Tuple[int, *Tuple[str, ...]], etc.

This replaces #2125 .

cc @mrahtz @gvanrossum

TypeVarTuples can be substituted with unbounded tuples.

gvanrossum · 2021-11-24T22:23:43Z

I'll review this once @mrahtz has approved it.

mrahtz

Lots of small comments, but basically looks good. Thanks, Pradeep, for getting this done so quickly!

pep-0646.rst

gvanrossum

I did not do a thorough review yet, but here are two nits.

In general, I worry a bit that this feels like a big rewrite, and as such the SC was right to un-approve the PEP and put it back in the queue. I doubt that they will end up rejecting it, but we are making more work for them, unless we add something like a cover letter when we resubmit saying "the update doesn't change anything fundamental, it just clarifies a bunch of stuff, and it makes one significant change (lifting the restriction on types with unknown length)." And they will still want to see for themselves that we're not (accidentally or intentionally) smuggling in something else.

pep-0646.rst

gvanrossum · 2021-11-25T22:32:14Z

pep-0646.rst

@@ -414,6 +354,133 @@ Normal ``TypeVar`` instances can also be prefixed and/or suffixed:
    z = prefix_tuple(x=0, y=(True, 'a'))
    # Inferred type of z is Tuple[int, bool, str]

+Unpacking a Tuple Type


We're already inconsistent, e.g. line 207 uses singular.

pradeep90 · 2021-11-26T04:50:25Z

@mrahtz Addressed all the comments.

@gvanrossum

In general, I worry a bit that this feels like a big rewrite

Yeah, I ignored the political aspect of it and just described from a technical point of view how tuple types affected certain sections :) Now that it's written down, we can trim any parts you feel aren't worth adding.

and as such the SC was right to un-approve the PEP and put it back in the queue. I doubt that they will end up rejecting it, but we are making more work for them, unless we add something like a cover letter when we resubmit saying "the update doesn't change anything fundamental, it just clarifies a bunch of stuff, and it makes one significant change (lifting the restriction on types with unknown length)." And they will still want to see for themselves that we're not (accidentally or intentionally) smuggling in something else.

A cover letter sounds good. We could say that we have preserved all of the old behavior and described some behavior that was previously unspecified or forbidden.

Main changes:

Describe how to unpack tuple types.
Remove section "Type Variable Tuples Must Have Known Length", which was an artificial restriction.
Explain how Array without type arguments actually works.
Explain how *args: *Tuple[<...>] works.
Explain how Callable[[int, *Ts, str], None] works.

We can cut (4) if needed. Readers can infer it using (1).

mrahtz · 2021-12-02T12:49:53Z

@gvanrossum Just checking, are the next steps here for you to give us a thorough review of these changes, or for us to try making the delta smaller to minimise SC concerns? (If it's the former and you just haven't got round to it yet, no worries!)

gvanrossum · 2021-12-02T15:58:46Z

The former. I will get to it.

gvanrossum

I'm pretty happy here! Bunch of plural/singular nits, and one place where I think an example should actually be an error (but maybe I'm missing something).

pep-0646.rst

gvanrossum · 2021-12-03T22:28:43Z

pep-0646.rst

@@ -414,6 +354,133 @@ Normal ``TypeVar`` instances can also be prefixed and/or suffixed:
    z = prefix_tuple(x=0, y=(True, 'a'))
    # Inferred type of z is Tuple[int, bool, str]

+Unpacking a Tuple Type


I'm guessing I am now definitely on the side of plurals.

pep-0646.rst

gvanrossum · 2021-12-03T22:41:17Z

pep-0646.rst

+The behavior of a Callable containing an unpacked item, whether the
+item is a ``TypeVarTuple`` or a tuple type, is to treat the elements
+as if they were the type for ``*args``. So, ``Callable[[*Ts], None]``


gvanrossum · 2021-12-03T22:43:45Z

pep-0646.rst

+When a generic class parameterised by a type variable tuple is used without
+any type parameters, it behaves as if the type variable tuple was
+substituted with ``Tuple[Any, ...]``:


Nice, isn't it! :-)

gvanrossum · 2021-12-03T22:44:52Z

pep-0646.rst

+unpacking ``Tuple[bool, bool]`` in the return type ``Tuple[float, *Ts,
+float]`` gives back ``Tuple[float, bool, bool, float]``.
+
+Unpacking an Unbounded Tuple Type


pep-0646.rst

gvanrossum · 2021-12-08T19:24:06Z

@pradeep90 Do you have time to finish this PR this week? We also have to consider #2177 and I'd like to get this moving to the SC again.

pradeep90 · 2021-12-08T21:17:15Z

Done! Sorry, was working with Steven on the callable PEP. Lmk if you have further thoughts :)

@mrahtz We'll probably need to update the *args: *Ts grammar section to mention *Tuple[<...>].

gvanrossum · 2021-12-08T21:54:37Z

Aargh! I wish you wouldn't force-push. Now GH won't show "commits since last review". But no worries, I'll figure it out.

gvanrossum

LGTM. I will merge this now, then we can move on to the other PR for this PEP, and then we can send it back to the SC (you can start drafting a cover letter now).

pradeep90 added 8 commits November 24, 2021 11:48

PEP 646: remove trailing spaces.

cfea45f

PEP 646: TypeVarTuple works like a tuple of types.

a898ac7

PEP 646: delete section about known length.

8fe6dfe

TypeVarTuples can be substituted with unbounded tuples.

PEP 646: explain how to unpack tuple types.

6a991b9

PEP 646: no type parameters means unbounded tuple.

645b7e4

PEP 646: unpack tuples to type *args.

2aed6a6

PEP 646: behavior for Callable with *Ts.

06618d8

PEP 646: only one unpacking in a tuple.

383a441

pradeep90 requested a review from gvanrossum as a code owner November 24, 2021 21:57

the-knights-who-say-ni added the CLA signed label Nov 24, 2021

mrahtz approved these changes Nov 25, 2021

View reviewed changes

gvanrossum reviewed Nov 25, 2021

View reviewed changes

pradeep90 force-pushed the master branch from 6d5c08b to 9bbc727 Compare November 26, 2021 04:31

pradeep90 force-pushed the master branch from 9bbc727 to b8becb6 Compare November 26, 2021 04:51

gvanrossum mentioned this pull request Dec 3, 2021

[PEP 646] Explicitly allow *args: *Tuple[*Ts, T] #2125

Closed

gvanrossum reviewed Dec 3, 2021

View reviewed changes

pradeep90 force-pushed the master branch 2 times, most recently from 321cb78 to 2548e68 Compare December 8, 2021 21:04

PEP 646: fix nits and typos.

04fe143

pradeep90 force-pushed the master branch from 2548e68 to 04fe143 Compare December 8, 2021 21:16

gvanrossum approved these changes Dec 8, 2021

View reviewed changes

gvanrossum merged commit f1c0224 into python:main Dec 8, 2021

pradeep90 mentioned this pull request Dec 15, 2021

Submission for SC consideration: PEP 646 -- Variadic Generics python/steering-council#59

Closed

pradeep90 mentioned this pull request Feb 28, 2022

bpo-43224: Implement PEP 646 changes to typing.py python/cpython#31021

Merged

pradeep90 mentioned this pull request Apr 29, 2022

PEP 646: Decide on substitution behavior python/cpython#91162

Closed

erlend-aasland mentioned this pull request May 13, 2022

pep8/greppable exception messages erlend-aasland/peps#1

Closed

erlend-aasland mentioned this pull request Jun 27, 2022

pep 687/mark as accepted erlend-aasland/peps#2

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[PEP 646] Allow cleanly substituting any tuple type for a TypeVarTuple #2162

[PEP 646] Allow cleanly substituting any tuple type for a TypeVarTuple #2162

pradeep90 commented Nov 24, 2021

gvanrossum commented Nov 24, 2021

mrahtz left a comment

gvanrossum left a comment

gvanrossum Nov 25, 2021

pradeep90 commented Nov 26, 2021

mrahtz commented Dec 2, 2021

gvanrossum commented Dec 2, 2021

gvanrossum left a comment

gvanrossum Dec 3, 2021

gvanrossum Dec 3, 2021

gvanrossum Dec 3, 2021

gvanrossum Dec 3, 2021

gvanrossum commented Dec 8, 2021

pradeep90 commented Dec 8, 2021

gvanrossum commented Dec 8, 2021

gvanrossum left a comment

[PEP 646] Allow cleanly substituting any tuple type for a TypeVarTuple #2162

[PEP 646] Allow cleanly substituting any tuple type for a TypeVarTuple #2162

Conversation

pradeep90 commented Nov 24, 2021

gvanrossum commented Nov 24, 2021

mrahtz left a comment

Choose a reason for hiding this comment

gvanrossum left a comment

Choose a reason for hiding this comment

gvanrossum Nov 25, 2021

Choose a reason for hiding this comment

pradeep90 commented Nov 26, 2021

mrahtz commented Dec 2, 2021

gvanrossum commented Dec 2, 2021

gvanrossum left a comment

Choose a reason for hiding this comment

gvanrossum Dec 3, 2021

Choose a reason for hiding this comment

gvanrossum Dec 3, 2021

Choose a reason for hiding this comment

gvanrossum Dec 3, 2021

Choose a reason for hiding this comment

gvanrossum Dec 3, 2021

Choose a reason for hiding this comment

gvanrossum commented Dec 8, 2021

pradeep90 commented Dec 8, 2021

gvanrossum commented Dec 8, 2021

gvanrossum left a comment

Choose a reason for hiding this comment