Aargh, too many messages!

- Constructor argument naming: For experimental use (before the bikeshed color is settled) I'd actually prefer TypeVarTuple, because it's a special import, and if it can't be imported that's a cleaner signal than a complaint about a parameter name. Agreed that a unique name like variadic is helpful. 

- Packed vs. Unpacked: Agreed that it's easier to experiment without the `*` syntax; and requiring `Unpack[Ts]` might be tedious for a prototype/experiment. But the parser work is not the reason to reject this. We should consider usability. Remember that PEP 637 will add support for `*` in all the right places anyway. (And certainly not in slices.) So the other work will (likely) have to happen anyway.

- PEP splitting: Yes. But eventually I want `Map[]` so that we can finally type zip() and map() properly -- this was the original impetus for variadics.

- Concatenation: Okay, supporting only `Tuple[t1, t2, Ts]` and not more complicated things like `Tuple[Ts1, Ts2]` or `Tuple[t1, Ts, t2]` is fine for the initial evaluation. (But thanks Pradeep for implementing it!)

- Concatenation in Callable: Okay, I can't think of any practical examples that aren't solved by ParamSpec either.

On Mon, Jan 25, 2021 at 8:46 AM Matthew Rahtz via Typing-sig <typing-sig@python.org> wrote:
Jukka, Ivan, Rebecca: You can skip to your names below.

**Constructor argument naming**

> The thing I like about a mouthful like "variadic" is that if you encounter it and don't know what it means you know you need to go look it up.

Hmm, good point. Let's keep this argument in mind if we do decide to use `TypeVar` as the constructor (which I'm still not sure we should).

**Packed vs unpacked**

> I'm a bit uncomfortable introducing a naming convention that makes significant changes to typing interpretation. That feels rather subtle.

> If I were to see `Tuple[Ts]` I'd have to remember that the naming convention tells me that the tuple is variadic. Readability Counts.
> I think the grammar change is for the best. It values explicitness over magic.

Hearing this opinion from Guido in particular updates me significantly. Still, I find myself wondering whether the small improvement in readability (of something that's only likely to be used in library code and therefore not terribly user-facing) is worth the cost to updating the parsers of at least CPython, Mypy, pytype and Pyright.

The main crux for me here is the exact degree of difficulty. Eric, when you said it would be a 'heavy lift', were you thinking mainly because of the complications of concatenation and Map? Based on your experiments in Pyright so far, how difficult would introducing the new grammar be? (**Jukka, Ivan, Rebecca**, it would be super useful to hear your thoughts here too. In case a catch-up would be helpful: the question is, if we wanted to make it so that our new 'variadic type variable' was used as `Ts = TypeVarTuple('Ts'); class Foo(Generic[*Ts]): ...; foo: Foo[int, str] = Foo()`, how hard would that be, considering the new use of the star?)

**PEP splitting**

The latest draft of the PEP is: https://github.com/python/peps/pull/1781

I've split `Map` and fancier concatenation off into separate documents (https://docs.google.com/document/d/1szTVcFyLznoDT7phtT-6Fpvp27XaBw9DmbTLHrB6BE4 and https://docs.google.com/document/d/1sUBlow40J7UwdTSyRYAj34ozkGOlMEjPaVEWeOmMfS8, respectively, though haven't cleaned them up yet).

I've also tried tentatively rewriting it so that a `TypeVarTuple` behaves as if unpacked by default, eliminating the star. Everything does still seem to work, and admittedly the PEP seems much simpler.


> Can you clarify what "no concatenation of variadics" refers to? Does this mean we can't (yet) have `Tuple[int, *Ts]`? Or is that specifically about `Tuple[*Ts1, *Ts2]`. (And what about the same constructs inside `Callable[[<here>], R]`?

I like Eric's proposal of a) only prefixing is allowed, and b) allowing only a single variadic type variable. For `Callable`, I think we shouldn't allow concatenation at all, at least not in this PEP - a) because it's simpler, b) because if we did `Callable[[int, Ts], R]` then the first argument would have to be positional-only, and that feels like it's going to have complications I haven't thought through yet, and c) because I expect most use-cases would be covered by PEP 612. I've updated the draft correspondingly.

--Guido van Rossum (python.org/~guido)