Attack a sacred Python Cow

[Jordan]

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.)