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. -- http://mail.python.org/mailman/listinfo/python-list
