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 -- http://mail.python.org/mailman/listinfo/python-list
