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 https://testfixtures.readthedocs.io/en/latest/api.html#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 firstname.lastname@example.org wrote:
On Sat, Jul 25, 2020 at 10:15:16PM -0500, Henry Lin wrote:
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?
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 -- 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/TDLFBU... Code of Conduct: http://python.org/psf/codeofconduct/