[Python-Dev] Equality on method objects

[Guido van Rossum]

On Sun, Mar 9, 2008 at 9:51 AM, Adam Olsen <rhamph at gmail.com> wrote:
> On Sun, Mar 9, 2008 at 9:02 AM, Armin Rigo <arigo at tunes.org> wrote:
>  > Hi all,
>  >
>  >  In Python 2.5, I made an attempt to make equality consistent for the
>  >  various built-in and user-defined method types.  I failed, though, as
>  >  explained in http://bugs.python.org/issue1617161.  The outcome of this
>  >  discussion is that, first of all, we need to decide which behavior is
>  >  "correct":
>  >
>  >     >>> [].append == [].append
>  >     True or False?
>  >
>  >  (See the issue tracker for why the answer should probably be False.)
>  >
>  >  The general question is: if x.foo and y.foo resolve to the same method,
>  >  should "x.foo == y.foo" delegate to "x == y" or be based on "x is y"?
>  >
>  >  The behavior about this has always been purely accidental, with three
>  >  different results for user-defined methods versus built-in methods
>  >  versus method wrappers (those who know what the latter are, raise your
>  >  hand).
>  >
>  >  (Yes, Python < 2.5 managed three different behaviors instead of just
>  >  two: one of the types (don't ask me which) would base its equality on
>  >  the identity of the 'self', but still compute its hash from the hash of
>  >  'self'...)
>
>  They should only compare equal if interchangeable.  In the case of a
>  mutable container (ie list), a value comparison of self is irrelevant
>  garbage, so it should always be compared (and hashed) based on
>  identity.
>
>  IOW, "x = []; x.append == x.append" should be True, and everything
>  else should be False.

Perhaps. I think we should approach this from the perspective of what
is the most useful behavior that is straightforward to implement, not
what is "right" (since there is more than one "right"). Do we have
much of a use case for this? If not, I'd be okay with not providing
these various forms of bound methods with equality at all, and just
fall back on 'is'. While it may be surprising that x.append is not
x.append, it should be no more surprising than x+1 is not x+1 under
certain circumstances, and both actually provide a useful insight into
the implementation.

That said, if there's a use case, I agree that it would be okay with
basing the equality of x.foo and y.foo on whether x and y are the same
object, not on whether x==y (consider 0 .__add__ == 0.0 .__add__).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)