[issue37555] _CallList.__contains__ doesn't always respect ANY.

Change by Irit Katriel : -- stage: patch review -> resolved status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Irit Katriel added the comment: 3.8 is in security fix mode now, so I think this issue can be closed. -- resolution: -> fixed status: open -> pending ___ Python tracker ___

[issue37555] _CallList.__contains__ doesn't always respect ANY.

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 class I

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Karthikeyan Singaravelan added the comment: I would prefer not backporting this change given the discussion in https://github.com/python/cpython/pull/14700#issuecomment-531791029 -- ___ Python tracker

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Irit Katriel added the comment: Does this need a backport? It's in 3.9 but not 3.8. -- nosy: +iritkatriel ___ Python tracker ___

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Paul Ganssle added the comment: New changeset d6a9d17d8b6c68073931dd8ffa213b4ac351a4ab by Paul Ganssle (Elizabeth Uselton) in branch 'master': bpo-37555: Update _CallList.__contains__ to respect ANY (#14700) https://github.com/python/cpython/commit/d6a9d17d8b6c68073931dd8ffa213b4ac351a4ab

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Serhiy Storchaka added the comment: See issue37685. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37555] _CallList.__contains__ doesn't always respect ANY.

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 everything.

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Serhiy Storchaka added the comment: This issue is a part of more general issue. I have opened a thread on Python-Dev for discussing it: https://mail.python.org/archives/list/python-...@python.org/thread/VSV4K4AOKM4CBQMOELPFV5VMYALPH464/. -- ___

[issue37555] _CallList.__contains__ doesn't always respect ANY.

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, and

[issue37555] _CallList.__contains__ doesn't always respect ANY.

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

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Change by Karthikeyan Singaravelan : -- nosy: +cjw296, mariocj89, michael.foord ___ Python tracker ___ ___ Python-bugs-list mailing

[issue37555] _CallList.__contains__ doesn't always respect ANY.

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. I've

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Paul Ganssle added the comment: Maybe I am missing something, but while it is true that DjangoModel is doing the wrong thing by returning False instead of NotImplemented, the `ANY` sentinel is supposed to match *anything*, not just things that compare equal to it, right? I would expect this

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Karthikeyan Singaravelan added the comment: Thanks Elizabeth for the test. The regression test seems to be same as the case noted by Serhiy that Foo.__eq__ is not returning NotImplemented so that ANY.__eq__ can be executed. Below would be the correct implementation that passes. The actual

[issue37555] _CallList.__contains__ doesn't always respect ANY.

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 respecting ANY

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Serhiy Storchaka added the comment: Would be nice to report a bug in Django. -- ___ Python tracker ___ ___ Python-bugs-list

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Serhiy Storchaka added the comment: You can take it, please. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Karthikeyan Singaravelan added the comment: I can see difference in time.__eq__ and timedelta.__eq__ C and Python implementations. Serhiy, are you planning to fix them or shall I raise an issue with PR for these? -- ___ Python tracker

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Karthikeyan Singaravelan added the comment: Good catch, commenting out the c implementation of datetime in setup.py I can see the following difference. ➜ cpython git:(master) ✗ ./python.exe Python 3.9.0a0 (heads/master-dirty:c8e7146de2, Jul 12 2019, 15:51:00) [Clang 7.0.2 (clang-700.1.81)]

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Serhiy Storchaka added the comment: Yes, see timedelta.__eq__ for example. datetime.__eq__ looks correct. -- ___ Python tracker ___

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Karthikeyan Singaravelan added the comment: https://docs.python.org/3/library/unittest.mock.html#any 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

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Serhiy Storchaka added the comment: Though some __eq__ implementations in the stdlib should be fixed too. -- ___ Python tracker ___

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Serhiy Storchaka added the comment: Then I think the problem is with DjangoModel. I suggest to close this issue as "third party". -- ___ Python tracker ___

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Karthikeyan Singaravelan added the comment: > Karthikeyan, I think there is a flaw in your example. The good __eq__ should > return NotImplemented instead of False for other types. This wil allow the > right operand's __eq__ to play. Serhiy, my example was to try reproducing the original

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Serhiy Storchaka added the comment: Karthikeyan, I think there is a flaw in your example. The good __eq__ should return NotImplemented instead of False for other types. This wil allow the right operand's __eq__ to play. -- nosy: +serhiy.storchaka

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Karthikeyan Singaravelan added the comment: Thanks for the report. Can you please add an example without Django or other dependencies so that I can try reproducing it? I am trying out the below program from the report where Foo has overridden __eq__ to return False if the other object being

[issue37555] _CallList.__contains__ doesn't always respect ANY.

Change by Roundup Robot : -- keywords: +patch pull_requests: +14499 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14700 ___ Python tracker ___

[issue37555] _CallList.__contains__ doesn't always respect ANY.

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, Decimal('20') ),