`--strict-equality` not aware of custom `__eq__` override in child class

[jez]

Bug Report

The --strict-equality flag does not account for potential to have custom __eq__ implementation in a child class.

It looks like --strict-equality attempts to detect when there is a custom __eq__ method, and in this case suppresses any potential "non-overlapping equality check." But this custom equality method override might be on a child class, not the parent class, defeating the check.

I could be convinced this is just an accepted limitation of the --strict-equality flag, but I'm curious to hear your thoughts on the matter.

To Reproduce

→ View on mypy-play.net

class Parent(object):
    pass
class Child(Parent):
    def __eq__(self, other):
        True

class CustomEq(object):
    def __eq__(self, other):
        True

class Unrelated(object):
    pass

def example1(x: CustomEq, y: Unrelated):
    if x == y:
        print(x)

def example2(x: Parent, y: Unrelated):
    if x == y:
        print(x)

example1(CustomEq(), Unrelated()) # prints

example2(Parent(), Unrelated()) # does not print
example2(Child(), Unrelated())  # prints

Expected Behavior

The equality check in example2 could return true, which is an argument against reporting an error here.

In this case it's made to return True trivially, but you could imagine an implementation of the __eq__ method on Child that does in fact use other to decide whether the check returns True or False.

Actual Behavior

main.py:19: error: Non-overlapping equality check (left operand type: "Parent", right operand type: "Unrelated")  [comparison-overlap]
Found 1 error in 1 file (checked 1 source file)

Your Environment

See associated playground link.

• Mypy version used: 0.991
• Mypy command-line flags: --strict-equality
• Mypy configuration options from mypy.ini (and other config files): n/a
• Python version used: n/a

[hauntsaninja]

Yeah, it's an accepted limitation.

It's not too bad in practice because Python tends to be strongly typed, so things from separate class hierarchies usually don't compare equal to begin with.

Taking the possibility of child classes into account would mean --strict-equality could only work between two final classes (with no custom eq), of which there are few.

I can also imagine cases where this error is welcome even in the presence of child classes with custom eq.

Here's a different case you might find interesting. Since object.__bool__ just returns True, sometimes user code contains conditionals that don't do anything. We have a check for this, but it's currently off by default for fear of subclasses with custom __bool__ or __len__, since unlike __eq__ across different types it's hard to have an opinionated prior: https://mypy.readthedocs.io/en/stable/error_code_list2.html#check-that-expression-is-not-implicitly-true-in-boolean-context-truthy-bool