Author xtreak
Recipients ElizabethU, serhiy.storchaka, xtreak
Date 2019-07-12.09:17:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>

mock.ANY doesn't make any guarantees that this is a generic implementation that can be used to test equality against any object irrespective of the order to return True. It's documented only to be used for mock calls but there are many users using it for other objects too outside of mock assertions. mock.ANY also depends on the order so that mock.ANY.__eq__ is used but I am not sure about documenting the order here.

Would be helpful if Elizabeth presents a simplified example to evaluate if there are any bugs in the call comparison with ANY or to close it as third party as suggested. As noted in my PR comment there should be a test case for this change proposed to make sure someone doesn't change the order by accident in future :

> Though some __eq__ implementations in the stdlib should be fixed too.

Curious about what problems that this example surface in the stdlib definition of __eq__ . Are you saying that there are Django model like __eq__ definitions where they return False when other's type is different?
Date User Action Args
2019-07-12 09:17:46xtreaksetrecipients: + xtreak, serhiy.storchaka, ElizabethU
2019-07-12 09:17:46xtreaksetmessageid: <>
2019-07-12 09:17:46xtreaklinkissue37555 messages
2019-07-12 09:17:46xtreakcreate