Constructors in subclasses should have same signature or not?

[amacfie-tc]

The Python docs state¹

The fact that Type[C] is covariant implies that all subclasses of C should implement the same constructor signature and class method signatures as C.

Does this only apply to classes that we put as arguments to Type or to all classes? On the one hand, subclasses have differing constructor signatures all the time, e.g. dataclasses. On the other hand, without this constraint we can do things like this:

class A:
    def __init__(self, a: int):
        print(a + 1)

    @classmethod
    def f(cls, a: int) -> Self:
        return cls(a)


class B(A):
    def __init__(self, x: str):
        print(x + "1")

which Pyright doesn't find any errors in.

---

1. The docs then say "The type checker should flag violations of this, but should also allow constructor calls in subclasses that match the constructor calls in the indicated base class." which I don't understand.

[erictraut]

Pyright intentionally exempts __init__ calls from its override checks. Mypy appears to do the same. It's not uncommon for Python code to have different signatures for __init__ within the same class hierarchy, so it would be noisy if type checkers were not to exempt this. This does admittedly leave a potential type checking hole.

[JelleZijlstra]

Yes, the docs here seem wrong, or at least inconsistent with current practice. They do reflect the text of PEP 484: https://peps.python.org/pep-0484/#the-type-of-class-objects.

In practice (as Eric also said), type checkers allow incompatible __init__ overrides, because flagging them would be too disruptive. This does mean that Type[] is unsound.