Annoying behaviour of the != operator

[Peter Hansen]

Robert Kern wrote:
> The problem arises that, in the presence of rich comparisons, (a == b) 
> is not always a boolean value, while (a is b) is always a boolean value. 

But that still doesn't mean that in a case where a == b (via __eq__) 
returns a non-boolean, __ne__ would not be defined as well.  In other 
words, there's _nothing_ preventing this "fix" from being made to 
provide saner behaviour in the most common case (which happens to pose 
the greatest risk of inadvertent mistakes for those who aren't aware of 
the requirement to define both) while still allowing the cases that need 
unusual behaviour to get it by (as they already surely do!) defining 
both __ne__ and __eq__.

-Peter