Incompatible singledispatch signature not detected

[JukkaL]

This generates no error from mypy but fails at runtime:

from functools import singledispatch

@singledispatch
def f(x: object) -> int:
    return 1

@f.register
def _(x: int, y: str) -> int:
    return 2

print(f(1))  # No error reported, but fails at runtime

Another example:

from functools import singledispatch

@singledispatch
def f(x: object, y: str) -> None:
    y + ''

@f.register
def _(x: int, y: int) -> None:
    y + 1

print(f(1, 'x'))  # No error reported, but fails at runtime

Third example:

from functools import singledispatch

@singledispatch
def f(x: object, y: str) -> None:
    pass

@f.register
def _(x: int, yy: str) -> None:
    pass

print(f(1, y='x'))  # No error reported, but fails at runtime

We should check that the signatures of registered items are compatible with the generic one, except for the first argument.

[pranavrajpal]

Example 1 should be relatively easy to support, but examples 2 and 3 have some subtlety involved.

For example 2, I don't know if we should allow arguments of registered implementations to be subtypes of the corresponding main singledispatch function's arguments, or whether we should require that they be the exact same types.

Example:

from functools import singledispatch

class A: pass
class B(A): pass

@singledispatch
def f(x: object, y: A) -> None:
    y + ''

@f.register
def g(x: int, y: B) -> None:
    y + 1

Allowing subtypes for the arguments could allow directly calling g to correctly error if you have something like g(5, A()), which wouldn't have been caught if the second parameter had been required to be A.

On the other hand, allowing subtypes could mask errors when calling f because we ignore the registered functions entirely when type checking calls to f. That means that something like f(5, A()) would be an error but wouldn't be caught when type checking. Requiring that the type of y be A in g would at least make it more obvious that mypy won't be able to help in that case and that g should handle the case that y isn't an instance of B but is an instance of A.

Example 3 seems like a singledispatch version of #6709, because I wouldn't be surprised if there is a lot of code that uses different argument names between implementations and then just never uses keyword arguments in calls.

I still think it's worth trying to show an error for, but we might have to abandon it if there are too many false positives. Alternatively, we could try putting this error behind a flag that gets enabled by --strict similar to what #6709 (comment) suggests.

[JukkaL]

I don't know if we should allow arguments of registered implementations to be subtypes of the corresponding main singledispatch function's arguments, or whether we should require that they be the exact same types.

I think that they should be allowed to vary contravariantly (i.e. registered implementations can use a more general type, but not a narrower subtype). This would be consistent with how method overriding is type checked.

Example 3 seems like a singledispatch version of #6709, because I wouldn't be surprised if there is a lot of code that uses different argument names between implementations and then just never uses keyword arguments in calls.

Yeah, it would be reasonable to not require argument names to be consistent, since we don't check them in other contexts.