Description
class A:
def foo(self, s: str) -> str: ...
class B(A):
def foo(self, n: float) -> float: ... # type: ignore
class C(B):
def foo(self, n: float) -> float: ...Mypy is correct to report an error for B.foo that necessitated a type: ignore comment. However, having added that type: ignore for B.foo, mypy should not also report an error for C.foo. Although C.foo is inconsistent with A.foo, it’s consistent with B.foo, and I have already asked mypy to ignore the inconsistency between B.foo and A.foo.
To put this another way, I recognize that mypy would fail to catch the runtime error in a: A = C(); a.foo("str"), but this would still be a runtime error if C.foo did not override B.foo, so the blame should be assigned solely to B.foo and not to C.foo.
This comes up in the typeshed stubs for markdown.inlinepatterns:
class Pattern:
def handleMatch(self, m: Match) -> Optional[Union[str, Element]]: ...
class InlineProcessor(Pattern):
def handleMatch(self, m: Match, data) -> Union[Tuple[Element, int, int], Tuple[None, None, None]]: ... # type: ignoreThese stubs correctly reflect the upstream API which uses handleMatch with a different signature in subclasses of InlineProcessor than in other subclasses of Pattern. That wasn’t a great API design decision, but now that it’s made and the type: ignore was added to InlineProcessor.handleMatch, ideally I shouldn’t have to repeat the same type: ignore in order to write a custom subclass of InlineProcessor whose handleMatch satisfies the signature of InlineProcessor.handleMatch.