Executing the body of an abstractmethod

[decorator-factory]

When using abstractmethod, the body of an abstract method is allowed to be executed through a super() call. (or by simply calling Duck.quack(some_duck) here)

from abc import ABC, abstractmethod

class Duck(ABC):
    @abstractmethod
    def quack(self):
        print("the base quacking behaviour")

class LoudDuck(Duck):
    def quack(self):
        super().quack()
        print("QUACK!")

LoudDuck().quack()  # will print 'the base quacking behaviour' and 'QUACK'

Leaving the body as just pass is very common (see flink, standard library), even if the return type of the method doesn't allow None:

from abc import ABC, abstractmethod

class Duck(ABC):
    @abstractmethod
    def quack(self) -> str:
        pass

A mixin class like this will not work safely with Duck, because if someone eventually calls Duck.quack, they're going to get a surprising None value:

class LoudDuck(Duck):
    def quack(self) -> str:
        return super().quack().upper() + "!"

LoudDuck().quack()  # TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

Mypy does complain about the LoudDuck class:

Call to abstract method "quack" of "Duck" with trivial body via super() is unsafe  [safe-super]

Of course, this safeguard will not work if the type checker only considers pyi files for the library, so this is fine with mypy:

class Increment(SupportsInt):
    def __int__(self) -> int:
        return super().__int__() + 1 

int(Increment())  # will try to add None to 1

pyright does not report an error with either Duck, LoudDuck or Increment.

---

My question is: leaving the body of a method that is not allowed to return None as pass is typically not allowed by type checkers. Abstract method bodies can be executed, so why are they exempt from this rule?