"Jordan Rastrick" wrote: > I'd suggest the only nessecary change is, if objects a,b both define > __eq__ and not __ne__, then a != b should return not (a == b) > > If a class defines __ne__ but not __eq__, well that seems pretty > perverse to me. I don't especially care one way or another how thats > resolved to be honest. > > The ordering comparisons (__lt__, __ge__ etc) are fine as they are I'd > say, since they only come up in the rare cases where __cmp__ isn't > sufficient. > > I'll wait for a bit more discussion on here before starting a PEP - as > I've said I'm only a beginner, and a more experience Pyonista may yet > give a perfectly good argument in favour of the current behaviour. >
I've been bitten by this particular wart more than once, so I wrote a metaclass for automating the addition of the missing rich comparisons with the expected semantics: == and != are complementary, and given either of them and one of <, >, <=, >=, the other three are defined. You can check it out at http://rafb.net/paste/results/ymLfVo81.html. Corrections and comments are welcome. Regards, George -- http://mail.python.org/mailman/listinfo/python-list
