In the following code, PyCharm is issuing a typing warning for Base.foo ("Expected to return 'int', got no return") but not for Base.bar, which has exactly the same typing hint and return type:

import abc

class Base(abc.ABC):
    @abc.abstractmethod
    def foo(self) -> int:
        print('fooing')
        pass

    @abc.abstractmethod
    def bar(self) -> int:
        pass

class Derived(Base):
    def foo(self) -> int:
        return 42

    def bar(self) -> int:
        return 42

In practice, neither Base.foo nor Base.bar can be called directly, so I'd expect no typing warnings at all there. If, on the other hand, one were to return super().foo() in Derived.foo, then a typing warning should indeed be issued, but the same should apply for Derived.bar so I still don't understand why the different behavior. Can someone explain, or is this a bug in PyCharm?

解决方案

Base.foo can be called, from an otherwise correct override of foo. Your type checker isn't tracing the execution of your code to ensure that Base.foo isn't called: you could have code like

class Derived2(Base):
    def foo(self) -> int:
        return 42 + super().foo()

which requires Base.foo to return an int.

Yes, Base.bar could also be called in the same way, but the empty body implies that there is no reason to do so. The type-checker special case that allows the empty abstract method to violate its typing is necessary because the ABC mechanism provides no way to separate the "declaration" of an abstract method from a definition. The only workaround to avoid the need for the special case would be to inject an annotated name directly into the private __abstractmethods__ attribute (which is essentially all the abstractmethod decorator does)

class Base(ABC):
    bar: Callable[[], int]

Base.__abstractmethods__.append("bar")

(The above is not tested, and it may not work even with additional tweaking. But I think we'd agree that this isn't something we'd want to write, hence the special handling by type checkers. In the end, Python-the-language has no support for base classes; it's provided entirely by a library module, and one designed long before type-checking was a thing to consider.)