Well, I'll admit I haven't ever used the Numeric module, but since PEP207 was submitted and accepted, with Numeric as apparently one of its main motivations, I'm going to assume that the pros and cons for having == and ilk return things other than True or False have already been discussed at length and that argument settled. (I suppose theres a reason why Numeric arrays weren't just given the same behaviour as builtin lists, and then simple non-special named methods to do the 'rich' comparisons.)
But again, it seems like a pretty rare and marginal use case, compared to simply wanting to see if some object a is equal to (in a non object identity sense) object b. The current situation seems to be essentially use __cmp__ for normal cases, and use the rich operations, __eq__, __gt__, __ne__, and rest, only in the rare cases. Also, if you define one of them, make sure you define all of them. Theres no room for the case of objects where the == and != operators should return a simple True or False, and are always each others complement, but <, >= and the rest give an error. I haven't written enough Python to know for sure, but based on my experience in other languages I'd guess this case is vastly more common than all others put together. I'd be prepared to bet that anyone defining just __eq__ on a class, but none of __cmp__, __ne__, __gt__ etc, wants a != b to return the negation of a.__eq__(b). It can't be any worse than the current case of having == work as the method __eq__ method describes but != work by object identity. So far, I stand by my suggested change. -- http://mail.python.org/mailman/listinfo/python-list
