type: ignore for “incompatible with supertype” error in subclass should suffice for subsubclasses too

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 playground link

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: ignore

These 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.

Reproduisez le comportement de vérification des sous-classes dans le mypy playground lié, puis comparez-le aux stubs de typeshed dans stubs/Markdown/markdown/inlinepatterns.pyi et à l’implémentation upstream dans markdown/treeprocessors.py. C’est terminé lorsqu’un type: ignore sur InlineProcessor.handleMatch empêche également une erreur inutile incompatible-with-supertype pour une redéfinition compatible dans une sous-classe, tandis que le diagnostic B.foo d’origine reste supprimé.