Look at the following example: ``` def some_function(f1: int): assert isinstance(f1, int) def other_function(f0: str, **kwargs): assert isinstance(f0, str) some_function(**kwargs) other_function(f0='a', f1='b') ``` I would expect a static type checker to warn that f1='b' is wrong because the type should be int. There shouldn't be a need to add a type to **kwargs since what is accepted can be deduced from how it is used. Note that some_function could be defined in another module and be used in multiple places, thus the "don't repeat yourself" and "separation of concerns" principles apply. Better to have the type for f1 be only in the definition of some_function and not in the **kwargs. I created a github issue in pyright (https://github.com/microsoft/pyright/issues/3583) and the response was that PEP 484 forbids this. I have seen that there are discussions about TypedDict for more precise typing of **kwargs. However, requiring to use TypedDict for the cases in which it is possible to derive what **kwargs accepts based on its use, seems over-complicating things, which is yet another principle "keep it simple, stupid". I would think that it wouldn't be too problematic to have a PEP stating that static type checkers when **kwargs has not type annotation are allowed to analyze the source code to identify what **kwargs accepts. I would even say that when **kwargs has a type, checkers are allowed to analyze how it is used. Also that the type annotation for **kwargs be not necessary if it is possible to deduce what it accepts. Anyway, I am just giving out this idea to see what happens. As a side note, I have been developing jsonargparse which can be used for automatically creating complex parsers based on signatures (https://jsonargparse.readthedocs.io/en/stable/#classes-methods-and-functions). I do plan to support identifying what **kwargs accepts based on its use. See all the cases currently supported https://jsonargparse.readthedocs.io/en/latest/#ast-resolver.