@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 <steve@pearwood.info> wrote:
On Sun, Jul 26, 2020 at 07:47:39PM +0200, Marco Sulla wrote:
> On Sun, 26 Jul 2020 at 19:33, Henry Lin <hlin117@gmail.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__()

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7N3GMYKC46MRA4DUNS2C5R2CA4CJGMOG/
Code of Conduct: http://python.org/psf/codeofconduct/