Repository navigation
Seemingly valid classmethod in subclass of generic generates incompatible return type error #7401
Description
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.
Activity
JukkaL commentedon Aug 29, 2019
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
Bazthat inheritsooffromBaz, 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 ofBazthat doesn't overrideoof.JukkaL commentedon Aug 29, 2019
Closing as duplicate of #2511.