Open Daverball opened 7 months ago
For addtional context, this was originally discovered in this typeshed PR for the wsgify.__call__
overloads: https://github.com/python/typeshed/pull/11460/files#diff-d3561ae2db2a1abf8fe4b07affa2cd97d72b2f4a257ce9f59fec9ac761c2dce4R99-R106
Bug Report
Sometimes functions are overloaded in a way where the same positional argument (usually the very first one) is reused for different kinds of objects, affecting the outcome. So for documentation purposes it can be nice to give that argument a different name depending on the overload. As long as that argument is positional-only and that particular overload doesn't also take **kwargs, the name of the argument should be ignored when matching against the original function signature, as long as the argument matches positionally, that should be good enough, there's only a safety issue if you can also pass the same argument by name in that overload.
To Reproduce
Source:
Stub:
Expected Behavior
stubtest is fine with accepting the first overload as a possibility
Actual Behavior
It looks like when you do that, stubtest will complain on the first overload, since there's no
number
argument, and then also complain on the second overload, because it will now infer that the original function must look likedef foo(number: int = ..., number_or_number: str = ...)
for some reasonYour Environment
mypy.ini
(and other config files):