Element size mismatch with TypeVarTuple and default arguments

[cdce8p]

Describe the bug

  error: Argument of type "*tuple[int]" cannot be assigned to parameter "args"
        of type "*Ts@run_callback" in function "run_callback"
    Type "*tuple[int]" cannot be assigned to type "*tuple[int, str]"
      Element size mismatch; expected 2 but received 1

To Reproduce

from typing import Callable
from typing_extensions import Unpack, TypeVarTuple

Ts = TypeVarTuple("Ts")

def func(x: int, y: str = "Hello") -> None: ...

def run_callback(callback: Callable[[Unpack[Ts]], None], *args: Unpack[Ts]) -> None:
    # ...
    callback(*args)


run_callback(func, 3)  # error

Expected behavior
run_callback(func, 3) should be valid since y has a default argument.

VS Code extension or command-line
1.1.264

Additional context
For reference the relevant PEP section: https://peps.python.org/pep-0646/#type-variable-tuples-with-callable
However, AFAICT the specific interaction with default arguments in Callables isn't mentioned.

[erictraut]

Yeah, this won't work as you're hoping. Unlike ParamSpec, TypeVarTuple doesn't have any way to capture the notion of a parameter with a default. In your example, Ts either takes on the type of tuple[int, str] or tuple[int]; it can't be both. I suppose it would be theoretically possible to track both and have the constraint solver eliminate one or the other later in the process, but that would add significant complexity to something that's already very complex, so I'm not inclined to add that.

You can work around this by not using default arguments or using @functools.partial or a lambda wrapper to eliminate the parameters with default arguments.

[cdce8p]

I suppose it would be theoretically possible to track both and have the constraint solver eliminate one or the other later in the process, but that would add significant complexity to something that's already very complex, so I'm not inclined to add that.

That's unfortunate, I suspect it will limit the usefulness of TypeVarTuples in Callables. In just one project, I already came across multiple errors because of it. Especially since it's such a common pattern with async code in particular. E.g. https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.call_later

Of course functools.partial would work, but that negates the purpose of adding type hints in the first place as I would lose type checking completely.

[erictraut]

The use of functools.partial shouldn't eliminate type checking. Pyright (and mypy) have special knowledge of functools.partial, so it should work fine.

[cdce8p]

The use of functools.partial shouldn't eliminate type checking. Pyright (and mypy) have special knowledge of functools.partial, so it should work fine.

My experience so far has been to avoid partial as much as possible and unfortunately, it doesn't seem to work in this case

from functools import partial
run_callback(partial(func, 3))

  test.py:16:1 - error: Argument of type "tuple[()]" cannot be assigned to parameter "args" of type "*Ts@run_callback" in function "run_callback"
    Type "tuple[()]" cannot be assigned to type "*tuple[str]"
      Element size mismatch; expected 1 but received 0 (reportGeneralTypeIssues)

[erictraut]

Ah, I forgot that partial has this weird behavior with default arguments. Yeah, that won't work. A lambda will work though.

run_callback(lambda x: func(x), 3)

[cdce8p]

A lambda will work though.

I'm not really convinced that is a good option. The arguments of lambda are untyped, so we again lose type checking for *args.

reveal_type(lambda x: func(x))  # (x: Unknown) -> None

More importantly, using a lambda would complicate an already difficult to understand function call. Especially when passing more than one or two arguments. In the end, it's not a feasible solution IMO.

--

Yeah, this won't work as you're hoping. Unlike ParamSpec, TypeVarTuple doesn't have any way to capture the notion of a parameter with a default. In your example, Ts either takes on the type of tuple[int, str] or tuple[int]; it can't be both. I suppose it would be theoretically possible to track both and have the constraint solver eliminate one or the other later in the process, but that would add significant complexity to something that's already very complex, so I'm not inclined to add that.

I don't know the internals of pyright. However, from my rough understanding of things I'm not sure it needs to be that complicated. Of course, it's necessary to track whether a parameter has a default argument. Once you do though, it's only necessary to compare the first x arguments and end the check. It should help that TypeVarTuples can only be used for *args, so the argument order will always match.

def func(x: int, y: str = "Hello", z: float = 1) -> None: ...

run_callback(func, 3)  # ok
run_callback(func, 3, "World")  # ok
run_callback(func, 3, 2.4)  # error -> y missing

[erictraut]

TypeVarTuples capture tuples, not parameter signatures. At the point where the func argument is processed by the type checker, it needs to convert the parameter signature of func to a tuple and associate that tuple with Ts. Should it associate *tuple[int, str] or should it associate *tuple[int]? I think the rules need to be unambiguous here, and it makes the most sense to treat parameters with default arguments the same as parameters without default arguments — that is, it should associate *tuple[int, str] with Ts in this example.

Let's consider what would happen if we allowed both of these tuples to be associated with Ts. First, it's not just two tuples in the general case. We would need to associate n tuples where n is the number of default arguments in the callable's signature.

What happens if we associate n tuples with Ts but Ts appears just once in the target call's parameter signature? What is the final type of Ts in this case? We would need to pick from among the list of tuples. The final type would be ambiguous because it would not be clear which of these tuples is the correct solution. I suppose we could use some heuristic (pick the longest tuple?), but that's not a very satisfying answer.

def func1(cb1: Callable[[*Ts], None]) -> tuple[*Ts]:
    ...

def func2(x: int, y: int = 0, z: int = 0) -> None: ...

func1(func2) # Type is ambiguous; could be tuple[int] or tuple[int, int]

Now let's consider what happens if Ts appears multiple additional times in the target call's signature. I suppose it would be possible to prune tuples from the list of contenders and hope that you end up with just one in the end, but this gets very complicated to implement, and any resulting errors would be difficult to explain to users.

def func1(cb1: Callable[[*Ts], None], cb2: Callable[[*Ts], None]) -> tuple[*Ts]:
    ...

# func2 has 3 parameters including 2 with default arguments.
# It translates to tuple[int], tuple[int, int], or tuple[int, int, int].
def func2(x: int, y: int = 0, z: int = 0) -> None: ...

# func3 has 4 parameters including 2 with default arguments
# It translates to tuple[int, int], tuple[int, int, int], or tuple[int, int, int, int].
def func3(a: int, b: int, c: int = 0, d: int = 0) -> None: ...

func1(func2, func3) # Type is tuple[int, int]? tuple[int, int, int]?

I don't think the authors of PEP 646 contemplated this use case. It's not mentioned in the PEP, and the behavior is undefined and ambiguous if parameters with default arguments are treated differently from parameters without default arguments at the time the TypeVarTuple captures a tuple from a callable's parameter signature.

I understand why you want this case to be supported. It makes sense in the straightforward case in your sample, but it falls apart (becomes ambiguous) and becomes very complex (requires tracking much more information and computing intersections of tuple lists) in the general case.

For now, pyright will continue to convert parameter signatures to tuples in a straightforward and unambiguous way when handling TypeVarTuples.

I'd be willing to revisit this decision in the future if the authors of PEP 646 clarify their intent in this case, preferably as an amendment to the existing PEP or a new follow-on PEP.

[cdce8p]

Thanks for the detailed answer! I was perhaps a bit too narrowly focused on my example without considering the general case. It's not a full nor particularly good solution, but what if support for default arguments is limited to cases where Ts isn't part of the return type? In these instances, it should only be necessary to keep track of defaults and do input type checking. That could allow supporting the (probably) most common case without adding ambiguity.

I've opened python/typing#1231 to discuss how to handle this case further.

[erictraut]

it should only be necessary to keep track of defaults

As I said above, TypeVarTuples don't capture parameter signatures, so it doesn't make sense to speak of "keeping track of defaults". TypeVarTuples capture tuples, and there is no concept of a "default" with a tuple.

You should think of this as a transform that converts a callable's parameter signature into a tuple. This transform fails for some signatures, such as those with keyword-only parameters or **kwargs. Signatures that include default arguments can be converted to multiple different tuples. Pyright's current implementation chooses the most natural conversion, which ignores the presence of the default arguments.