I'm encountering a situation where it would be far cleaner to use **kwargs (multiple functions taking the same set of parameters); I'd like to have type hints, and avoid repeating multiple function definitions, explicitly enumerating all parameters for each function definition.
Therefore, I'd like to have some meaningful type hint for **kwargs. First, I thought TypedDict would be a great fit, until I found this passage in PEP 589:
These features were left out from this PEP, but they are potential extensions to be added in the future:
...
TypedDict can't be used for specifying the type of a **kwargs argument. This would allow restricting the allowed keyword arguments and their types. According to PEP 484, using a TypedDict type as the type of **kwargs means that the TypedDict is valid as the value of arbitrary keyword arguments, but it doesn't restrict which keyword arguments should be allowed. The syntax **kwargs: Expand[T] has been proposed for this [11].
...
In the mypy issue discussion, there seems to be two issues:
1. Ambiguity of whether the type hint applies to the **kwargs dict vs. each value in the dict. I think this could be a red herring; kwargs presents as a dict and I think TypedDict can unambiguously represent the structure of that dict. I don't see how it should be different than any other dict parameter being defined as a function parameter.
2. A question of whether one needs to assume that for a TypedDict, the type validator should assume total=False. I think what keys are required should be explicitly determined by the TypedDict (required keys inferred from total). I suspect the issue could be that mypy may not be able to determine this during static type analysis?
In summary, **kwargs is a dict; TypedDict can specify its structure; static type checker limitations should not necessarily restrict its use in this way.
Therefore, I propose a short PEP be drafted to codify the validity of using TypedDict to specify the type of a **kwargs argument.
Paul