Member

Fixes #16082

Currently we only allow Unpack of a TypedDict when it appears in a function definition. This PR also allows this in Callable types, similarly to how we do this for variadic types.

Note this still doesn't allow having both variadic unpack and a TypedDict unpack in the same Callable. Supporting this is tricky, so let's not so this until people will actually ask for this. FWIW we can always suggest callback protocols for such tricky cases.

Contributor

Diff from mypy_primer, showing the effect of this PR on open source code:

graphql-core (https://github.com/graphql-python/graphql-core): typechecking got 1.06x slower (313.1s -> 331.1s)
(Performance measurements are based on a single noisy sample)

Member

So to be clear this allows Callable[[Unpack[TD]], T], where TD is a TypedDict. It's pretty obvious what that means, but I don't think any PEP prescribes it (PEP 692 says nothing about Callable[]), so I'm uncomfortable adding this to mypy without further discussion and buy-in from other type checkers.

Member Author

@JelleZijlstra I don't like the model where people outside of mypy have to say anything about whether a given feature should be in mypy or not. We can coordinate on details of semantics of certain constructs, to achieve better compatibility (especially for use in typeshed), but this doesn't really apply here, since semantics is quite obvious.

Contributor

This idea could even be extended to ParamSpec:

P = ParamSpec("P")
class C(Generic[P]):
    def __init__(self, f: Callable[P, None]): ...
class Args(TypedDict):
    x: int
    y: str
def f(*, x: int, y: str) -> None: ...
c: C[[Unpack[Args]]] = C(f)  # OK
d: C[[int, str]] =  = C(f)  # error because `f` expects keyword arguments?

Member Author

@tmke8 Yes, this is totally possible. It however may be a bit trickier to implement (and I am busy with other things now). You can open a separate issue for this.