This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Missing equality check for super objects
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.9
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: JelleZijlstra Nosy List: JelleZijlstra, ZackerySpytz, rhettinger
Priority: low Keywords:

Created on 2016-06-07 20:48 by JelleZijlstra, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (6)
msg267747 - (view) Author: Jelle Zijlstra (JelleZijlstra) * (Python committer) Date: 2016-06-07 20:48
>>> class Foo: pass
... 
>>> super(Foo) == super(Foo)
False

Will submit a patch later
msg267753 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-06-07 23:16
Why would you need this?   

Also, would it interfere with super's ability to use the __eq__ method for a parent class?

    class A:
        def __eq__(self, other):
            return True

    class B(A):
        def __eq__(self, other):
            return super(B, self).__eq__(other)

    print(B() == B())
msg267781 - (view) Author: Jelle Zijlstra (JelleZijlstra) * (Python committer) Date: 2016-06-08 05:10
This came up as part of a static analysis script that compares sets of method calls, including calls to methods on super(). The check was giving incorrect results because identical super() objects were comparing as different.

super() is documented (https://docs.python.org/3/library/functions.html#super) as only delegating lookups for explicit attribute lookups, not for implicit lookups like that done by the == operator, so I think it would be safe to override tp_richcompare in C on super objects. In writing my patch, I'll be sure to test that the code you gave still works correctly though.
msg267875 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-06-08 17:40
I don't think this should be done.
msg350520 - (view) Author: Zackery Spytz (ZackerySpytz) * (Python triager) Date: 2019-08-26 10:29
> I don't think this should be done.

I agree, and I think this issue should be closed.
msg350675 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-08-28 17:10
Though not beautiful, we already have a way to fulfill this rare use case:

    >>> class Foo():
            pass

    >>> s = super(Foo)
    >>> t = super(Foo)
    >>> (s.__self_class__, s.__self__) == (t.__self_class__, t.__self__)
    >>> True

Though awkward to write, it is completely explicit.  That makes it better than giving "s == t" a profoundly different meaning than "s.__eq__(t)".  IMO that would be an API mistake, making it tricky to do code review and requiring special knowledge of a rare corner case.
History
Date User Action Args
2022-04-11 14:58:32adminsetgithub: 71447
2019-08-28 17:10:12rhettingersetstatus: open -> closed
versions: + Python 3.9, - Python 3.6
messages: + msg350675

resolution: rejected
stage: resolved
2019-08-26 10:29:36ZackerySpytzsetnosy: + ZackerySpytz
messages: + msg350520
2016-06-08 17:40:29rhettingersetmessages: + msg267875
2016-06-08 05:12:47JelleZijlstrasetpriority: normal -> low
type: enhancement
2016-06-08 05:10:28JelleZijlstrasetmessages: + msg267781
2016-06-07 23:16:59rhettingersetnosy: + rhettinger
messages: + msg267753
2016-06-07 20:48:03JelleZijlstracreate