Implementation of overloaded functions not properly checked

[bo5o]

Bug Report

Mypy does not seem to check overloaded functions.

To Reproduce

script.py

from typing import Union, overload


@overload
def foo(a: str) -> str:
    ...


@overload
def foo(a: int) -> int:
    ...


def foo(a: Union[str, int]) -> Union[str, int]:
    if isinstance(a, str):
        return 1  # type error expected
    return "one"  # type error expected

Expected Behavior

I expected mypy to tell me I am providing the wrong return type.

Actual Behavior

$ mypy script.py
Success: no issues found in 1 source file

Your Environment

I tested on Ubuntu 18.04 with mypy version 0.782 and 0.790+dev.89695cd476a06108051637c85455a57042d0f988 and python version 3.7.9 and 3.8.6 with default mypy settings.

[bo5o]

The documentation actually describes the behavior here, so maybe this is more a feature request.

[gvanrossum]

There's no way that a static checker will be able to follow the implementation and tell you whether it is returning the wrong type given the argument types, so I am closing this.

[bo5o]

Okay, thank you very much for clarifying!

This does leave me with some questions though and maybe someone can quickly point out why it is impossible (or provide a link/reference)?

I admittedly have limited understanding of static type checking internals, but here is my understanding of the problem:

If I try

reveal_type(a)

inside the if block, it correctly tells me that a is now a string. It does also know the 2 overload variants I provided earlier (since it does complain if I do not respect them in the actual function implementation). Now I would expect that internally it has matched the first @overload as the only possible variant and the return type must now be a string as well.

What am I missing?

[gvanrossum]

For further discussion please see Gitter.

[vnmabus]

For further discussion please see Gitter.

Sorry, can someone point me to the discussion? Why the implementation cannot simply be checked with all defined overloads, and just report the union of all errors? I think the current behaviour limits the usefulness of overload.

[bo5o]

@vnmabus If you scroll back to Sep. 29, 2020 in https://gitter.im/python/typing you might find the discussion, I actually don't know if there is a better way to search gitter.

From what I remember, someone said that adding this functionality would be a substantial increase in complexity of the type checker, which probably outweighs the benefits. For a deeper understanding I guess you'd have to take a look at the actual code.

[vnmabus]

I have found it, thanks @cbows. Maybe I am saying something stupid, but I think that the implementation could be type-checked n times (with n equal to the number of overloads), switching the types to match each overload, and report the errors found ignoring unreachable branches. I am not sure how complex that would be, but it does not seems that substantial at first glance.