@Steven D'Aprano
- 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?)
On Sun, Jul 26, 2020 at 8:29 PM Steven D'Aprano
On Sun, Jul 26, 2020 at 07:47:39PM +0200, Marco Sulla wrote:
On Sun, 26 Jul 2020 at 19:33, Henry Lin
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 -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7N3GMY... Code of Conduct: http://python.org/psf/codeofconduct/