Avoid specialized assert formatting when we detect that `__eq__` is overridden

The issue reported for introspecting numpy arrays #5347, is still present for dataclasses when invoking assertrepr_compare.

When testing:

from dataclasses import dataclass
import numpy as np


@dataclass
class A:
    a: np.ndarray
    
    def __eq__(self, other):
        return np.array_equal(self.a, other.a)


def test_fails():
    assert A(np.array([1,2])) == A(np.array([2,1]))

Instead of an “Drill down” explanation you get:

   def test_fails():
>       assert A(np.array([1,2])) == A(np.array([2,1]))
E       assert A(a=array([1, 2])) == A(a=array([2, 1]))
E         (pytest_assertion plugin: representation of details failed: .../_pytest/assertion/util.py:430: ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all().
E          Probably an object has a faulty __repr__.)

(Ubuntu 21.10, pytest 6.25, python 3.9)

One way to solve it: since pytest only sees difference on repr perhaps instead of comparing arr1 == arr2 when determining if the fields are different, perhaps it should consider whether repr(arr1) == repr(arr2) which sidesteps the issue with array not returning bool for comparison.

Instead of https://github.com/pytest-dev/pytest/blob/14b79a66a31281c7aa5334f958c9b40aadc259c5/src/_pytest/assertion/util.py#L444-L448

one could do

    for field in fields_to_check:
        if repr(getattr(left, field)) == repr(getattr(right, field)):
            same.append(field)
        else:
            diff.append(field)

If the __repr__s are the same and the object are not the same (or vice versa), then the explanation shown by pytest will regardless be misleading.

[asottile]

@RonnyPfannschmidt that would create a bug in the other direction in the default case (since dataclass is just going to use == and if we used numpy’s comparison then it would be different)

[hynek]

JFTR attr.s doesn’t ignore a custom eq if auto_detect=True. In attr.define it’s on by default.

I‘m planning on adding an __attrs_effective_params__ (https://github.com/python-attrs/attrs/issues/602) but didn’t get around to it yet. 😦