I had a chance to review the latest draft. Here's my feedback... In the latest draft, TypeTupleVar and TypeVarTuple seem to be used interchangeably. I assume this is just a typo and that one will be preferred over the other. Why do we think it’s important to support both packed and unpacked versions of TypeVarTuple? Why not simplify this and support with only unpacked versions? I find it very confusing that both are supported, and I see relatively little value in supporting the non-unpacked version. This simplification would also allow us to eliminate TypeVarTuple and stick with TypeVar. The expression `*T` would denote a variadic TypeVar, and `T` would be a non-variadic. The spec indicates that variance and bound are not supported. I presume that constrained (restricted) types are also not supported? If so, that should be specified. I presume that if a generic class can use at most one TypeVarTuple, and it’s an error if more than one is used. I also presume that the TypeVarTuple must be last in the type variable list, and it’s an error if not. These assumptions should be called out explicitly in the spec. [When I got further into the spec, this question was answered, but contrary to my assumptions here.] The spec talks about an unpacked TypeVarTuple used with *args and says that a TypeVarTuple can’t be used with **kwargs. Am I correct in assuming that an unpacked TypeVarTuple cannot be used with a simple parameter (not *args or **kwargs)? If so, this should be specified. The spec says that TypeVarTuples can be used with Callable. The sample shows a single use of a TypeVarTuple, and it’s unpacked. I presume that at most one unpacked TypeVarTuple can appear in a Callable parameter list and it must be the last parameter in the list? The spec says that TypeVarTuples can be used with Union. The sample shows a single use of TypeVarTuple, and it’s unpacked. I presume that more than one TypeVarTuple can appear in a Union? And all must be unpacked? I understand the motivation behind adding `Map` to this spec, but I don’t think it’s a very strong motivation. I would _strongly_ advocate for its removal. I think it unnecessarily complicates an already complex PEP. It effectively adds higher-kinded type support but in a limited and half-thought-out manner. To support `Map`, type checkers will need to do most of the work required to support higher-kinded types. That’s a lot of work with relatively little benefit. I’d rather save this functionality for a future PEP that introduces higher-kinded types in a proper and holistic manner. Map appears to work only with generic types that have an arity of 1. Am I correct in that assumption? If so, it feels very constraining. In the section on concatenation, the spec’s example shows that the unpacked TypeVarTuple (`*Shape`) appears as the last element in the subscript. Since it’s used for TypeVar matching, I presume that at most one TypeVarTuple can appear in a list like this and it needs to be unpacked. If my assumptions are correct, those should be documented. [When I got further into the spec, this question was answered, but contrary to my assumptions here.] The concatenation indicates that both prefixing and suffixing are supported. How important is the use case for suffixing? It adds some (not insignificant) complexity to the implementation to support this in a type checker, and I’m not convinced the use cases merit this added complexity. Can you provide some concrete use cases that could help make the case for suffixing? The section “Concatenating Multiple Type Variable Tuples” clarifies some of my questions above but provides an answer I was hoping not to hear. Supporting multiple TypeVariableTuples adds _significant_ complexity, and in most use cases I can think of will result in ambiguities (and therefore errors). The spec provides some examples of where these ambiguities can be resolved, but my preference is to disallow the use of multiple type variable tuples in all cases. This is another case of where the added complexity doesn’t seem to be merited given the limited usage. Summary: I think there are some great ideas in this PEP, but I also think it’s unnecessarily complex in some areas. My recommendations (in priority order): 1. Remove `Map`. Please! 2. Remove support for multiple TypeVarTuples in a type expression. 3. Remove support for unpacked usage. Don’t introduce new TypeVarTuple and use regular TypeVar but with unpack to indicate a TypeVarTuple. 4. Remove support for concatenation suffixing. -- Eric Traut Contributor to pyright and pylance Microsoft Corp.