classification
Title: Fix minor inconsistency in the order of == operands
Type: Stage: resolved
Components: Interpreter Core Versions: Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, josh.r, serhiy.storchaka, xtreak
Priority: normal Keywords: patch

Created on 2019-07-22 07:58 by serhiy.storchaka, last changed 2019-09-13 09:43 by xtreak. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 14904 merged serhiy.storchaka, 2019-07-22 08:13
Messages (3)
msg348287 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-07-22 07:58
There is two ways to write the comparison when we search an item equal to the needle:

    item == needle

and

    needle == item

In most cases they get the same result. But if __eq__ of the item or the needle is not correctly implemented (returns False instead of NotImplemented for unsupported types) the order can matter. We want the behavior be consistent in all cases.

The majority of the code uses needle on the right side of the == operator. But there are few outliners:

* tuple.__contains__ and list.__contains__. They code is different from the code used in methods count(), index(), remove() where needle is on the right.

* The general implementation of the "in" operator for iterators (see PySequence_Contains).

* dictitems.__contains__.

* The copy of list_contains in _ssl.c.

* The C implementation of _asyncio.Future.remove_done_callback. It differs from the Python implementation.

In all other code (many tens of occurrences) needle is on the right.

I think it is worth to fix the minor inconsistency in these few places.

See also the discussion on Python-Dev: https://mail.python.org/archives/list/python-dev@python.org/thread/VSV4K4AOKM4CBQMOELPFV5VMYALPH464/.
msg348981 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-08-04 11:12
New changeset 18b711c5a7f90d88fb74748f18fa8ef49d8486c7 by Serhiy Storchaka in branch 'master':
bpo-37648: Fixed minor inconsistency in some __contains__. (GH-14904)
https://github.com/python/cpython/commit/18b711c5a7f90d88fb74748f18fa8ef49d8486c7
msg352262 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2019-09-13 09:43
Just to add list.__contains__ and others might cause subtle changes as noted. One example is around discussion at https://github.com/python/cpython/pull/14700#discussion_r324054193 where my code to fix mock.ANY was depending on this behavior to work on master and didn't work with 3.8 since it's not backported. mock.ANY depends on the order of operands.
History
Date User Action Args
2019-09-13 09:43:23xtreaksetmessages: + msg352262
2019-08-04 11:14:56serhiy.storchakasetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2019-08-04 11:12:51serhiy.storchakasetmessages: + msg348981
2019-07-22 13:41:36josh.rsetnosy: + josh.r
2019-07-22 08:24:05xtreaksetnosy: + xtreak
2019-07-22 08:14:08serhiy.storchakasetnosy: + gvanrossum
2019-07-22 08:13:34serhiy.storchakasetkeywords: + patch
stage: patch review
pull_requests: + pull_request14682
2019-07-22 07:58:57serhiy.storchakacreate