Seemingly valid classmethod in subclass of generic generates incompatible return type error

[erickpeirson]

Are you reporting a bug, or opening a feature request?

Encountered an unexpected behavior (bug?) when working with classmethods on generics. It is also possible that I have misunderstood how this is supposed to work.

Please insert below the code you are checking with mypy,

Here is a minimal example:

T = TypeVar('T')
Self = TypeVar('Self', bound='Foo')

class Foo(Generic[T]):
    a: T

    def __init__(self, a: T) -> None:
        self.a = a

    @classmethod
    def oof(cls: Type[Self], a: T) -> Self:
        return cls(a)


class Baz(Foo[str]):
    @classmethod
    def oof(cls, a: str) -> 'Baz':  # error: Return type "Baz" of "oof" incompatible with return type <nothing> in supertype "Foo"
        return cls(a)

What is the actual behavior/output?

With mypy==0.720, this generates:

error: Return type "Baz" of "oof" incompatible with return type 

What is the behavior/output you expect?

Given that

class Baz(Foo[str]):
    pass

reveal_type(Baz.oof('1'))  # note: Revealed type is 'ack.Baz*' 

I would expect there to be no error when I override the classmethod in the subclass, so long as it is not conflicting.

On the other hand, I can work around this by

class Baz(Foo[str]):
    @classmethod
    def oof(cls: Type[Self], a: str) -> Self:
        return cls(a)

Have been spending some time looking at #6418 and related issues.

[JukkaL]

I believe that this is technically a false positive. However, requiring the use of self types in all overrides seems kind of reasonable to me, so I wouldn't classify this as a bug but a missing feature.

The motivation for the check is that there could be a subclass of Baz that inherits oof from Baz, in which case mypy would be correct to complain (and incorrect to not complain). However, I think that this error condition could only be reported if there actually is a subclass of Baz that doesn't override oof.

[JukkaL]

Closing as duplicate of #2511.