Overloaded function signatures overlap with incompatible return types, class and Callable

[tharvik]

from typing import Any, Callable, overload

F = Callable[..., Any]

class A: ...

@overload
def f(exit: A) -> A: ...
@overload
def f(exit: F) -> F: ...

gives

asd.py:8: error: Overloaded function signatures 1 and 2 overlap with incompatible return types

which I don't understand. There is no overlap (expect that A is also a Callable), so, why the message?

[gvanrossum]

You've nailed the reason for the overlap: f(A) matches both variants. (For other reasons it's important to accept classes when a callable is needed.)

Note that mypy's @overload processing doesn't go down the alternatives until it finds a match -- it finds all matching alternatives and if there's more than one, simply requires that they have the same return type.

I think we should close this issue as "won't fix". However maybe we need to change the wording in PEP 484 to call out this behavior more. I've opened python/typing#253 to serve that discussion. Feel free to participate!

[tharvik]

Hum, I see, then IMO, PEP 484 should demand that, rather than merging every alternatives, force the mypy to find the "most accurate" type description; so that a general case can be written, and have some specific cases. For example, having a __getitem__ for a map accepting slice index, described as

@overload
def __getitem__(self, k: slice) -> List[_V]: ...  # specific
@overload
def __getitem__(self, k: _K) -> _V: ...  # generic

For now, let's close it.

[gvanrossum]

(FWIW, I think the tradition is to list the special cases first and the general case last.)

[tharvik]

(Haha, yeah, that's more readable in a way, updated the comment, now it looks nicer!)

[JukkaL]

Mypy lets you vary the return type even if multiple variants match if your signatures are ordered from narrower to more general. For example, this should be fine:

@overload
def f(x: int) -> str: ...
@overload
def f(x: object) -> object: ...

f(1)  # this is str
f('x')  # this is object
x = 1  # type: object
f(x)  # this is object, which is okay since str is a subclass of object

This would be a problem, though:

@overload
def f(x: int) -> object: ...
@overload
def f(x: object) -> int: ...  # bad

def g(x: object) -> int:
    return f(x) + 3   # the runtime type of x may be int and return value could be anything

g(1)
f(1) + 3   # an error

[tharvik]

@JukkaL But in the current case, it is not working, I tried reordering the overload definition but it doesn't help. From what you wrote, I would have though that the overload for A would be narrower than the overload for Callable.

[JukkaL]

If A is also callable (i.e., it has __call__), then this looks like a problem with subtyping of Callable values. There is already an open issue for this: #797. Also, mypy currently assumes that Callable can overlap with anything, which is another bug.

[gvanrossum]

The original problem looks like the second thing:

…

mypy currently assumes that `Callable` can overlap with anything