+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 email@example.com wrote:
On Sun, Jul 26, 2020 at 11:01 PM Ethan Furman firstname.lastname@example.org 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 -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/ZJYGN4... Code of Conduct: http://python.org/psf/codeofconduct/