Am 25.01.21 um 17:48 schrieb Eric Traut:
I'd strongly advise against this.
It would seem to lead to ambiguities when matching arguments with parameters. For example:
```python @overload def foo(arg1: bool=..., arg2: Literal[True]) -> str: ...
foo(True) # Does this match the overload? ```
Would the rule be "if there's any possible way to construe an argument list as matching an overload, it should be matched"?
This would follow normal Python rules. In the example above, it doesn't match as calling this would be a runtime error: ```python def foo(arg1: bool=..., arg2: Literal[True]) -> str: ... foo(True) ```
The code for matching arguments with parameters is already extremely complicated in a type checker because it needs to deal with *args parameters, **kwargs parameters, position-only separators, keyword-only separators, unpack operators on args, TypeVar assignments, ParamSpec parameter assignments (P.args, P.kwargs), and *args with variadic type variables. More complexity in this code is not needed!
This seems to be a trade-off between type checker complexity and user code/stubs complexity. I am obviously biased here, but simpler user code and stubs seems more desirable to me than simpler type checkers as it scales far worse. - Sebastian