What is the Use Case for Using *args as a Type Variable Tuple?

[adam-grant-hendry]

I don't understand the intended use case for *args as a Type Variable Tuple as laid out in PEP 646.

I don't understand why I wouldn't do what's recommended by typeshed and give *args the type object so it can be any type and then type narrow in the function body. It seems like the target method that processes *args is going to have to type narrow any way if its items are truly indeterminate in size and type.

Maybe it is used for top-level functions that use helper functions that accept *args? The PEP provides os.execle as an example, which passes args to os.execve, but typeshed seems to manage with using Any (granted, TypeVarTuple isn't supported by mypy yet). Again though, I would have just typed this as object.

What is the intended use case for *args as a Type Variable Tuple?

Update

Please feel free to also review my SO answer related to typing *args and **kwargs. I do not know when one should use TypeVarTuple for *args.

[TeamSpen210]

One use case is to pair it with a Callable, where the *args are passed in when it's called (perhaps with additional parameters added before or after). In that situation it serves a similar purpose to ParamSpec, except where keyword arguments aren't allowed.

Though you might need to be type narrowing inside the function, the important thing is that it lets you then transfer those types to the return type in whatever way is appropriate.

[adam-grant-hendry]

@erictraut Note also that in your example, the methods __init__() and as_tuple() have Ts appear only once, but this works because its contained within the context of a Generic, and that usage isn't made clear within the PEP.

From your explanation, it makes perfect sense that a type variable by itself, outside of the context of mapping between generic types, serves little (or no) value.

Could these usage notes be added to one or both of these?:

• Proposal: Convert the typing-module PEPs into a series of HOWTOs
• Document Structure and Wishlist

[AlexWaygood]

From your explanation, it makes perfect sense that a type variable by itself, outside of the context of mapping between generic types, serves little (or no) value.

This isn't correct. We tried to elaborate some of the other use cases in the docs for the Python 3.11 typing module, which we tried to make slightly more accessible than the PEP (since the PEP, as Eric describes, isn't meant as end-user documentation, and isn't meant to be a living document): https://docs.python.org/3.11/library/typing.html#typing.TypeVarTuple

Could these usage notes be added to one or both of these?:

Information on TypeVarTuples and variatic generics would be included in part 2.vi of python/cpython#91533, if I (or anybody else) ever gets round to putting significant work into actualising that proposal :)

[adam-grant-hendry]

This isn't correct

Just when I thought I couldn't get more confused...

Which part? My understanding or @erictraut 's explanation? His claim is the primary use case for typing *args with a TypeVarTuple is when used within Generics. This seems to contradict the 3.11 docs.

If there are use cases beyond the Generic, it seems the pyright warning

TypeVar "Ts" appears only once in generic function signature

is useful as an opt-in feature for a code reviewer to quickly find the locations where this occurs, but might lead to a significant number of false-positives, and that the statement

it's generally indicative of a user's misunderstanding of how type variables work. If the use of a TypeVar is unnecessary and provides no value in a particular case, you are probably doing something wrong.

is not correct.

Secondly, is TypeVarTuple meant to handle the case of *args being a heterogenous type of indeterminate arity? That is, is it meant to handle the case of a top-level function calling multiple helpers and preserving type information between calls, similar to ParamSpec and what @TeamSpen210 suggested?

[AlexWaygood]

Eric is of course correct that the usage of TypeVarTuple in generic classes is the primary use case the PEP authors had in mind, and this is probably going to be its primary use case in the world of scientific computing. But I think you're incorrect to say that other uses of TypeVarTuple have "little (or no) value". Please take a look at the examples we added to the typing documentation for 3.11 to see some of the other use cases: https://docs.python.org/3.11/library/typing.html#typing.TypeVarTuple.

I've also listed some of the places where typeshed might be able to use TypeVarTuple to improve its stubs here: python/typeshed#8708 (comment). Note that only one of these use cases involves a generic class parameterised by a TypeVarTuple; the majority of use cases involve generic functions. (This is mostly because typeshed does not have very many scientific-computing stubs packages in it, but is still illustrative of the fact that there are other use cases for TypeVarTuple outside of generic classes.)

[adam-grant-hendry]

But I think you're incorrect to say that other uses of TypeVarTuple have "little (or no) value".

"little (or no) value" does sound excessive, I agree. I was thinking I shouldn't use it for top-level functions calling helpers to preserve type information between calls, but this does seem to be a valid use case. Without that, I couldn't think of a common use case for it besides what Eric mentioned, which is why I said what I said.

Thank you for showing me the additional use cases! I'll consider Eric's use case in addition to the python docs use cases.