Incompatible signature in method with restricted overload for a generic class

[vnmabus]

Bug Report

When a method of a generic class has an overload for a particular type of the generic parameter, subclasses that don't have that particular value should be able to override the method without that overload, but currently aren't.

To Reproduce

Consider the following code:

T = TypeVar("T")
A_no_T = TypeVar(
    "A_no_T",
    bound="A[None]",
)


class A(
    Generic[T],
):

    @overload
    def method(
        self: A_no_T,
    ) -> None:
        pass

    @overload
    def method(
        self,
        t: T,
    ) -> None:
        pass

    def method(
        self,
        t: Optional[T] = None,
    ) -> None:
        return


class B(A[int]):

    def method(
        self,
        t: int,
    ) -> None:
        pass

Expected Behavior

The code should typecheck without errors.

Actual Behavior

The following error is raised

Mypy: Signature of "method" incompatible with supertype "A"  [override]
Superclass:
@overload
def method(self) -> None
@overload
def method(self, t: int) -> None
Subclass:
def method(self, t: int) -> None

Your Environment

• Mypy version used: 0.931
• Mypy command-line flags: --follow-imports=silent --show-column-numbers --show-error-codes
• Mypy configuration options from mypy.ini (and other config files):
  strict = True
  strict_equality = True
  implicit_reexport = True
• Python version used: 3.8.0
• Operating system and version: Linux Ubuntu 18.04.6 LTS

[erictraut]

I don't think that's generally safe. What if the base class A contains the following?

    x: T

    def other_method(self):
        self.method(self.x)

Now if you call B().other_method(), the function B.method will get called with a None argument.

The problem is that when analyzing A, we don't know whether T has been bound to None, so the trick you're using to detect A[None] doesn't work in this case.

[vnmabus]

Sorry, but I don't get it. Surely x should have an int value in B, no?

[erictraut]

Sorry, forget what I said. My analysis was incorrect.

I think the issue is that mypy is validating the method implementation signature in the child class against the implementation signature in the parent class, but you want it to take into account the overload signatures in the child class as well.

[vnmabus]

Yeah, I think that is something sensible to do. In fact, requiring me to provide the first overload is wrong.

[erictraut]

I think this bug has been fixed. The latest version of mypy (1.5) no longer generates an error.

[hauntsaninja]

I fixed this in #14882