Overriding __post_init__ in child dataclass leads to type error

[aecay]

Note: if you are reporting a wrong signature of a function or a class in
the standard library, then the typeshed tracker is better suited
for this report: https://github.com/python/typeshed/issues

Please provide more information to help us understand the issue:

Consider the following test file:

from dataclasses import dataclass, InitVar


@dataclass
class Parent:
    x: int

    def __post_init__(self) -> None:
        print("hi!")


@dataclass
class Child(Parent):
    y: int
    z: InitVar[int]

    def __post_init__(self, z: int) -> None:
        print("hi from child; z is", z)


class OtherParent:
    def __init__(self):
        print("hi from other parent")


class OtherChild(OtherParent):
    def __init__(self, z: int):
        print("hi from other child; z is", z)


if __name__ == "__main__":
    Child(1, 2, 3)
    OtherChild(3)

Running mypy results in the following error:

% mypy dataclass_postinit_test.py
dataclass_postinit_test.py:17: error: Signature of "__post_init__" incompatible with supertype "Parent"
Found 1 error in 1 file (checked 1 source file)

I understand from #1237 that generally it is an error to have subclass methods that differ in this way. But it seems like __post_init__ should not fall into this category, and instead should be treated like __init__ which does not have any type checking error (as the example file also demonstrates with OtherParent/OtherChild).

[gvanrossum]

Interesting. I guess for now you can silence mypy with `# type: ignore` but you're right, ideally this ought to be special-cased. Truth be told there are probably some more magical functions in the stdlib for which we shouldn't insist on Liskov. I'm not sure where to go from here -- maybe you can find where `__init__` is special-cased in mypy and see how easy it would be to add `__post_init__`? (Luckily it's a dunder so we can just assume that it always has this property, not just when the class is decorated with `@dataclass`.)

[vnmabus]

Can a general solution be added, like a decorator that you can use in a base class method to not require Liskov in the subclass overrides? Because sometimes it is useful to have a special "startup" or "run" method that initializes the object and should be different for each subclass.

[sobolevn]

@vnmabus I think that typing.no_type_check can help. Or you can create your own based on typing.no_type_check_decorator.

[sobolevn]

Since I am working on #15498 I will also have a look at this one.