Hi Steven,

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;
Any class implementing the `__eq__` operator is no longer hashable
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.

In terms of the "popularity" of this potential feature, from what I understand (and through my own development), there are testing libraries built with this feature. For example, testfixtures.compare can compare two objects recursively, and I am using it in my development for this purpose.

On Sun, Jul 26, 2020 at 4:56 AM Steven D'Aprano <steve@pearwood.info> wrote:

On Sat, Jul 25, 2020 at 10:15:16PM -0500, Henry Lin wrote:
> Hey all,
>
> What are thoughts about implementing an object-compare function in the
> unittest package? (Compare two objects recursively, attribute by
> attribute.)

Why not just ask the objects to compare themselves?

assertEqual(actual, expected)

will work if actual and expected define a sensible `__eq__` and are the
same type. If they aren't the same type, why not?

actual = MyObject(spam=1, eggs=2, cheese=3)
expected = DifferentObject(spam=1, eggs=2, cheese=3)

> This seems like a common use case in many testing scenarios,

I've never come across it. Can you give an example where defining an
`__eq__` method won't be the right solution?

--
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/TDLFBURVX4N4JJP4ELIRLKULR775VNOY/
Code of Conduct: http://python.org/psf/codeofconduct/