@Steven D'Aprano email@example.com
- Developers might not want to leak the `__eq__` function to other
developers; I wouldn't want to invade the implementation of my class
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?)
On Sun, Jul 26, 2020 at 8:29 PM Steven D'Aprano firstname.lastname@example.org wrote:
On Sun, Jul 26, 2020 at 07:47:39PM +0200, Marco Sulla wrote:
On Sun, 26 Jul 2020 at 19:33, Henry Lin email@example.com wrote:
- Any class implementing the `__eq__` operator is no longer hashable
You can use:
def __hash__(self): return id(self)
Don't do that. It's a horrible hash function.
The `object` superclass already knows how to do a good, reliable hash function. Use it.
def __hash__(self): return super().__hash__()
-- Steven _______________________________________________ Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/7N3GMY... Code of Conduct: http://python.org/psf/codeofconduct/