@overload with identical arguments in the signature provides unexpected results.

[rdeaton]

First of all, I'd love to actually dig in and help fix this issue, just want to make sure that I choose the right path towards fixing it.

Came across some code similar to this recently:

@overload
def test(input: int) -> int:
    pass

@overload
def test(input: int) -> NoReturn:
    pass

def test(input):
    return 1

def test2() -> NoReturn:
    test(1)

The annotation on the arguments for both functions are identical, and with different return types, I would expect an error to be thrown indicating that you must vary the type annotations (and to update the documentation accordingly) since this is a nonsense case.

Actual results vary based on the order of the annotation. In the order above, no error or warning is raised. If we reverse the order, we do get

test2.py:16: note: Implicit return in function which does not return

Does adjusting the behavior of overload to raise an error if you have two definitions with identical call signatures sound like the right behavior?

Environment: Python 3.6.3, mypy 0.560

[gvanrossum]

It appears that nonsense overloads like this just result in the return type being Any:

@overload
def test(input: int) -> int:
    pass

@overload
def test(input: int) -> NoReturn:
    pass

def test(input):
    return 1

reveal_type(test(1))  # Revealed type is 'Any'

There are some plans to change the way mypy handles overloads, but we've not had the time to make this a priority. If you search the tracker for overload you'll see quite a few issues.

[ilevkivskyi]

I think this is essentially a duplicate of #1322. There Any is inferred instead of a union if multiple overloads match a function call.