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.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TEDDC7FU7TR6AESZT2NLHUYCKIJYFZTD/
Code of Conduct: http://python.org/psf/codeofconduct/
