> - Developers might not want to leak the `__eq__` function to other
> developers; I wouldn't want to invade the implementation of my class just
> for testing.
That seems odd to me. You are *literally* comparing two instances for
equality, just calling it something different from `==`. Why would you
not be happy to expose it?
My thinking is by default, the `==` operator checks whether two objects have the same reference. So implementing `__eq__` is actually a breaking change for developers. It seems by consensus of people here, people do tend to implement `__eq__` anyways, so maybe this point is minor.
I do appreciate the suggestion of adding this feature into functools though.
Let's assume we commit to doing something like this. Thinking how this feature can be extended, let's suppose for testing purposes, I want to highlight which attributes of two objects are mismatching. Would we have to implement something different to find the delta between two objects, or could components of the functools solution be reused? (Would we want a feature like this to exist in the standard library?)