False positive: in overloads, mypy is confused by `torch.Tensor` & `numpy.ndarray`

[Yura52]

Bug Report

(A clear and concise description of what the bug is.)

To Reproduce

# a.py
from typing import overload
import numpy
import torch

@overload
def f(a: numpy.ndarray) -> numpy.ndarray: ...

@overload
def f(a: torch.Tensor) -> torch.Tensor: ...

def f(a):
    return a + 1

mypy a.py

Expected Behavior

No errors reported by mypy, since this is a correct usage of overloading.

Actual Behavior

Overloaded function signature 2 will never be matched: signature 1's parameter type(s) are the same or broader

In fact, if torch overload is declared first, no errors are reported.

Environment

• macOS: 11.6
• VSCode: 1.68.1
• Pylance: v2022.6.20

I am working on this repository. So, my environment can be reproduced as follows:

# you can use conda instead of micromamba, the result is the same
micromamba create -n rtdl python=3.7
micromamba activate rtdl
pip install numpy=1.18.5 torch=1.7.1 scikit-learn=1.0.2
pip install -r requirements_dev.txt

[matteosantama]

What happens if you run mypy on

from typing import overload
import numpy
import torch

@overload
def f(a: numpy.ndarray) -> numpy.ndarray: ...

@overload
def f(a: torch.Tensor) -> torch.Tensor: ...

def f(a):
    return a + 1

reveal_type(numpy.ndarray)
reveal_type(torch.Tensor)

[erictraut]

I'm not able to repro the original problem reported in this bug report when using the latest published version of mypy (0.981). I suspect that a recent bug fix has addressed this issue.

[matteosantama]

I'm running into a similar problem but instead of torch.Tensor and numpy.ndarray it is two different types from an untyped library.

from typing import overload
import third_party_library as tpl

@overload
def f(a: tpl.Type1) -> tpl.Type1: ...

@overload
def f(a: tpl.Type2) -> tpl.Type2: ...

def f(a):
    # implementation

mypy is assuming the two types to be Any so the overloads are effectively both

@overload
def f(a: Any) -> Any: ...

@overload
def f(a: Any) -> Any: ...

This problem persists on 0.981. I wonder if in the numpy and torch case, those libraries have since added typing support.

[erictraut]

Both numpy and torch have been adding more type information over the past few releases. I'm using the latest published versions of each (numpy 1.23.3 and torch 1.21.1). It looks like the OP was using older versions of both, so it's quite likely that's the source of the problem here.