RE: __eq__ and __ne__

Discussion in 'Python' started by Tim Peters, Jul 8, 2003.

  1. Tim Peters

    Tim Peters Guest

    [Shane Hathaway]
    > I was surprised by the following behavior. Apparently, the "!="
    > operator does not fall back to using "not __eq__()".


    That's true -- there are no magical equivalences among the six rich
    comparison operators.

    > I tested this with Python 2.1, 2.2, and 2.2 with new-style classes and
    > got the same results in every case.


    Whew! I was afraid a bug may have slipped in <wink>.

    > >>> class foo:

    > ... def __eq__(self, other):
    > ... return (other.__class__ is self.__class__
    > ... and other.__dict__ == self.__dict__) ...
    > >>> foo() == foo()

    > 1
    > >>> foo() != foo()

    > 1
    >
    > I would expect the second test to yield "0". To compensate, I've
    > started adding the following boilerplate code to all classes that
    > define only __eq__:
    >
    > def __ne__(self, other):
    > return not self.__eq__(other)


    That's appropriate if that's what you what "!=" to mean.

    > Does this surprise anyone else? I have not yet found documentation
    > on this.


    The language (not library) Ref Man says this (under "Basic Customization"),
    and means what it says:

    The correspondence between operator symbols and method names is as
    follows: x<y calls x.__lt__(y), x<=y calls x.__le__(y), x==y
    calls x.__eq__(y), x!=y and x<>y call x.__ne__(y), x>y calls
    x.__gt__(y), and x>=y calls x.__ge__(y).

    In the richcmp PEP:

    http://www.python.org/peps/pep-0207.html

    point 3 under "Proposed Resolutions" gives one rationale:

    3 The == and != operators are not assumed to be each other's
    complement (e.g. IEEE 754 floating point numbers do not satisfy
    this). It is up to the type to implement this if desired.
    Similar for < and >=, or > and <=; there are lots of examples
    where these assumptions aren't true (e.g. tabnanny).

    A more involved (and probably more basic) rationale has to do with that the
    richcmp operators aren't constrained to return Boolean results; as the PEP
    says at its start:

    The main motivation comes from NumPy, whose users agree that A<B
    should return an array of elementwise comparison outcomes;

    Since the richcmp operators aren't constrained to return scalars, an attempt
    to define one in terms of the others seemed futile. Instead they're 6
    independent methods.
     
    Tim Peters, Jul 8, 2003
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shane Hathaway

    __eq__ and __ne__

    Shane Hathaway, Jul 8, 2003, in forum: Python
    Replies:
    0
    Views:
    401
    Shane Hathaway
    Jul 8, 2003
  2. Tim Peters

    RE: __eq__ and __ne__

    Tim Peters, Jul 16, 2003, in forum: Python
    Replies:
    0
    Views:
    411
    Tim Peters
    Jul 16, 2003
  3. Aaron Brady

    hash and __eq__

    Aaron Brady, May 30, 2009, in forum: Python
    Replies:
    14
    Views:
    688
    Albert van der Horst
    Jun 4, 2009
  4. INADA Naoki

    Is __ne__ method autogenerated?

    INADA Naoki, Dec 7, 2012, in forum: Python
    Replies:
    3
    Views:
    155
    INADA Naoki
    Dec 7, 2012
  5. Tim Delaney
    Replies:
    0
    Views:
    111
    Tim Delaney
    Feb 18, 2013
Loading...

Share This Page