"Jordan Rastrick" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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.)
They were - read the PEP again. That's the behavior they wanted to get away from. > 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. To quote Calvin Coolege: You lose. The primary open source package I work on, PyFit, always wants to do an equal comparison, and never needs to do a not equal. It also has no use for ordering comparisons. I do not equals as a matter of symmetry in case someone else wants them, but I usually have no need of them. Strict XP says I shouldn't do them without a customer request. > So far, I stand by my suggested change. I think most of your justification is simple chicken squaking, but write the PEP anyway. I'd suggest tightening it to say that if __eq__ is defined, and if neither __ne__ nor __cmp__ is defined, then use __eq__ and return the negation if and only if the result of __eq__ is a boolean. Otherwise raise the current exception. I wouldn't suggest the reverse, though. Defining __ne__ and not defining __eq__ is simply perverse. John Roth > -- http://mail.python.org/mailman/listinfo/python-list
