OK, it seems my original reply to Bruno got lost in the Aether (apologies therefore if a paraphrased "quantum duplicate" of this message is eventually forthcoming.)
Torsten has adequately responded to his second point, so I need only replicated what I said for the first. > Please get your facts, the behaviour *is* actually fully documented: I have the facts. I know full well the behaviour is documented - it was pointed out at the time of the original discussion. Documenting a confusing, unintuitive design decision (whether its in a programming language, an end user GUI app or anything in between) doesn't justify it. To attack a strawman: "foolanguage uses the bar IO library; printing to stdout takes about 10 mins on the average machine. But thats ok, because look, its documented right here." > FWIW, the __lt__ / __le__ / __eq__ / __ne__ / __gt__ / __ge__ methods > set, known as "rich comparisons", was added in Python 2.1 to give more > fine-grained control on comparisons. If you don't need such a > granularity, just implement the __cmp__ method and you'll have all > comparison operators working as expected. First, the most serious justification for rich comparisons I remember seeing was that scipy "needed" them. I never saw a good reason scipy couldnt use methods like the rest of us mortals, nor why it was justifiable introducing a wart into the entire language for the sake of mildly conveniencing an (admittedly important and widely used) library. Second, fine, have silly C++-operator-overloading-style rich comparisons that confuse people reading your code if you must. Why does it have to be the default behaviour? Its people wanting __ne__ do do something other than not __eq__ who should have to be explicit about it. Third, __cmp__ is no good as a fix. Most classes that wan't equality comparison (== and !=) don't want ordered based comparison (>= etc.) thrown in as well. I shouldn't implement __cmp__ unless I want my class to implement every order comparison operator. Fourth, I'm trying to examine the wider implications of the Explicit > Implict mantra here, not resurrect an old campaign to change != behaviour that I think is probably a lost cause (if it happens as a side effect though, that'd be kinda cool.) -- http://mail.python.org/mailman/listinfo/python-list
