Annoying behaviour of the != operator

[Rocco Moretti]

Before I answer, let me clarify my position. I am NOT advocating any 
change for the 2.x series. I'm not even forwarding any particular 
proposal for 3.0/3000. My key (and close to sole) point is that behavior 
of > & < is conceptually distinct from ordering in a sorted list, even 
though the behaviors coincide for the most common case of numbers.

>>One way to handle that is to refuse to sort anything that doesn't have
>>a "natural" order. But as I understand it, Guido decided that being
>>able to sort arbitrary lists is a feature, not a bug. But you can't
>>sort ones with complex numbers in them, because you also want
>>'1+3j<3+1j' to raise an error.
> 
> 
> As George Sakkis noted, Guido has since recanted.  Unfortunately, in
> this case, the time machine would have broken too much existing code.

As I mentioned in response, the referenced email only mentions the 
ability to use < & > in comparing arbitrary objects. My key point is 
that this is conceptually different than disallowing sorting on 
heterogeneous list. There are ways to disallow one, while still allowing 
the other.

> "Doesn't" and "can't" (call me pessimistic) comes from all the issues
> and disagreements we're having in this thread, and "shouldn't" comes
> from the Zen:
> 
>     Explicit is better than implicit.
>     In the face of ambiguity, refuse the temptation to guess.

Well, Python already "guesses implicitly", everytime you do a "1 + 2.0" 
or a "a + b", where 'a' doesn't define '__add__' and 'b' defines 
'__radd__' - The trick is to be clear and explicit (in the documetation) 
everytine you are implicit (in the running program). It's not guessing - 
it's a precisely defined part of the language.

>>>AIUI, __cmp__ exists for backwards compatibility, and __eq__ and friends
>>>are flexible enough to cover any possible comparison scheme.
> 
> 
>>Except if you want the situation where "[1+2j, 3+4j].sort()" works, and
>>'1+3j < 3+1j' fails.
> 
> 
> I'm sticking with my position that both should fail, unless you
> *explicity* tell sort what to do (since for now, we all seem to agree
> that the other one should fail).  If I have an application that thinks
> it has to sort a list of arbitrary objects, then I have to be clever
> enough to help.

Even if you decide to disallow sorting heterogenous lists, you still 
have the problem of what to do a user defined homogeneous list where 
__lt__ doesn't return a boolean. Moreso:

 >>Except if you want the situation where "[a, b].sort()" works, and
 >>'a < b' fails.

If you combine list sorting and >/< together, there is no way someone 
who wants >/< on a specific class to return a non-boolean value to have 
a homogeneous list of those objects sort the way they want them too.

If, on the other hand, you split the two and provide a sensible and 
explicitly defined fall-back order, then someone who doesn't care about 
the distinction can carry on as if they were combined. In addition, 
those people who want to sort lists of objects which return non-booleans 
for >/< can do that too.

BTW, the optional parameter for the sort function is not a suitable 
alternative. The main problem with it is where the sort order is 
encoded. The extra parameter in the sort has to be provided *every 
place* where sort is called, instead of a single place in the definition 
of the object. And you can't subclass the sort function in your user 
defined fuction, because sort is an operation on the list, not the 
objects in it.

And please don't say that always explicitly specifying the sort order is 
a good thing, unless you want the sort order to *always* be specified, 
even with builtins. (Sorting numbers? Ascending/Descending/Magnitude? - 
Strings? ASCII/EBDIC/Alphabetical/Case Insensitive/Accents at the end or 
interspersed? -- Okay, a little petulant, but the real issue is 
lists/tuples/dicts. Why isn't the sort order on those explicit?)


All that said, I'm not Guido, and in his wisdom he may decide that 
having a sort order different from that given by >/< is an attractive 
nuisance, even with user defined objects. He may then deside to disallow 
it like he disallows goto's and free-form indentation.