Repository navigation
Mypy incorrectly infers that parameters are positional-only for __eq__ methods autogenerated with @dataclass #12186
Description
For a class decorated with @dataclass, mypy assumes that the class's __eq__ method will have the exact same signature as object.__eq__. However, this is subtly incorrect. Whereas the signature of object.__eq__ is def __eq__(self, other: object, /) -> bool: ..., the signature of MyDataclass.__eq__ is def __eq__(self, other: object) -> bool: .... I.e., for the method auto-generated by @dataclass, the second argument is positional-or-keyword; whereas the second argument is positional-only for object.__eq__.
Minimal repro (using mypy 0.931, Python 3.10 -- try it on mypy playground here):
from dataclasses import dataclass
@dataclass
class Foo: ...
reveal_type(Foo.__eq__) # Revealed type is "def (builtins.object, builtins.object) -> builtins.bool"
Activity
AlexWaygood commentedon Feb 16, 2022
^FWIW, this isn't a purely theoretical issue. I'm writing a patch for stubtest, to increase its strictness when checking dunder methods. With my patch applied, stubtest complains that the
__eq__methods ofpstats.FunctionProfileandpstats.StatsProfilein the typeshed stubs are inconsistent with their__eq__methods at runtime, because the stub uses the@dataclassdecorator (cc @sobolevn, @hauntsaninja)JelleZijlstra commentedon Feb 16, 2022
It looks like the issue is that we don't actually generate an
__eq__method for dataclasses, so we end up inheriting the one fromobject. This code instead just generates a TypeVar: https://github.com/python/mypy/blob/master/mypy/plugins/dataclasses.py#L171.AlexWaygood commentedon Mar 29, 2022
Adding the "priority-low" label, since further updates to stubtest mean that this is no longer much of an issue.