+1 to Alex Hall.

In general I think there are a lot of questions regarding whether using the __eq__ operator is sufficient. It seems from people's feedback that it will essentially get the job done, but like Alex says, if we want to understand which field is leading to a test breaking, we wouldn't have the ability to easily check.

On Sun, Jul 26, 2020 at 4:13 PM Alex Hall <alex.mojaki@gmail.com> wrote:
On Sun, Jul 26, 2020 at 11:01 PM Ethan Furman <ethan@stoneleaf.us> wrote:
On 7/26/20 10:31 AM, Henry Lin wrote:

> You're right, declaring `__eq__` for the class we want to compare would
> solve this issue. However, we have the tradeoff that
>
>   * All classes need to implement the `__eq__` method to compare two
>     instances;

I usually implement __eq__ sooner or later anyway -- even if just for
testing.

>   * Any class implementing the `__eq__` operator is no longer hashable

One just needs to define a __hash__ method that behaves properly.

This is quite a significant change in behaviour which may break compatibility. Equality and hashing based only on identity can be quite a useful property which I often rely on.

There's another reason people might find this useful - if the objects have differing attributes, the assertion can show exactly which ones, instead of just saying that the objects are not equal. Even if all the involved classes implement a matching repr, which is yet more work, the reprs will likely be on a single line and the diff will be difficult to read. 
_______________________________________________
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/ZJYGN42PCO4J73AAM7ZZSVTOFHPBADWT/
Code of Conduct: http://python.org/psf/codeofconduct/