Elizabeth Uselton added the comment:
I believe it should work in both 3.8 and 3.9, the difference is that someone
(Serhiy if I'm remembering correctly?) did the work in 3.9 of standardizing
which side of the = the needle was on. So, this change works on 3.9 without the
_AnyComparer cl
Elizabeth Uselton added the comment:
Serhiy, thanks for pointing that out. I generally agree with everything in that
thread, and learned some new things (I had no idea count(), index() and
remove() used needle on the left side!) However, I'm not trying to spearhead a
rewrite of every
Elizabeth Uselton added the comment:
Giving this a reread with fresh eyes this morning, I realized I wasn't explicit
enough in saying that I see that this fix is about the same as the one you
mentioned, Karthikeyan, but said you were concerned might cause more subtle
bugs. I hear that
Elizabeth Uselton added the comment:
Just added a fix for the tests I added in the last commit showing the order
sensitivity in assertEqual when dealing with ANY and _Call or _CallList
objects. _Call and _CallList currently depend on ordering to correctly process
that an object being
Elizabeth Uselton added the comment:
I feel like I agree with Paul here, unsurprising behavior from ANY is it
matching anything, with no expectation that third party objects have to
correctly have a return path for NotImplemented on their __eq__ method. ANY
doesn't currently do that.
Elizabeth Uselton added the comment:
Hi there, I completely missed that this had caused so much interesting
discussion. I've added a regression test that shows the bug I was encountering,
which seems to be related to
spec_set bypassing _Call's overwritten __eq__ and so not resp
New submission from Elizabeth Uselton :
I have a test that goes something like:
```
@patch('a.place.to.patch')
def test_a_thing_calls_what_it_should(self, my_mock):
# Set up logic here
my_mock.assert_has_calls([
call(
ANY,
D
