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.

On Sun, 24 Jan 2021 at 23:33, Naomi Seyfer <naomi@seyfer.org> wrote:
I know I've been a bit of a lurker since this discussion got resurrected but:
2. RE: variadic=True, I'll echo an older comment of mine that "variadic"
is a bit of mouthful and hard to spell. Instead we might consider
something less technical like `tuple=True` or `many=True`.

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. If you see "variadic type" a google search is going to lead you to answers; if you try that for "many type" or "tuple type" it's not.
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
Member address: mrahtz@google.com