__eq__ and __ne__

[Tim Peters]

[Tim]
>>>> 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.

[Shane Hathaway]
>>> Ok.  Thanks for finding the docs.  I guess I'll stick to my
>>> boilerplate code.  I think some guidance should be added to the
>>> Python docs, though, explaining that whenever you define __eq__,
>>> you very likely ought to define __ne__ also.

Doc patches are always welcome <wink>.

[Jeremy Hylton]
>> I believe C++ has the same behavior when you overload logical
>> operators.  So at least people familiar with the same behavior in
>> other languages won't be surprised.

[Shane]
> Actually, C++ generates a compiler error if you try to do that.  (See
> the attached program.)  Java doesn't run into this because it has a
> simpler interface: the only operator you can override is equals().  So
> in this case, C++ is fully explicit and Java is fully implicit, while
> Python makes a guess.  If we can't make it implicit like Java, then it
> seems preferable for Python to raise an exception, similar to C++,
> when you use the != operator with an instance that implements __eq__
> but not __ne__.

With a clean slate, I'd agree.  If Python 3 supports *only* richcmps, I
expect that's what Guido will do there.  The current comparison mish-mash is
at least half backward-compatibility warts.  This is something that needs to
be simplified rather than complicated (it's already too complicated to
understand in all cases!), but simplification probably can't be done anymore
without breaking somebody's code.