
[Christian Tismer]
that people are putting widely different types into a list in order to sort them. (Although there is an arbitrary order between strings and numbers, which I would drop in Python 2.4, too).
[Alex Martelli]
Such a change would indeed enormously increase the number of non-sortable (except by providing custom compares) lists. So, for example, all places which get and sort the list of keys in a dictionary in order to return or display the keys should presumably do the sorting within a try/except?
I don't believe this argument. I've indeed often sorted a dict's keys (or values), but always in situations where the sorted values were homogeneous as far meaningful comparison goes, e.g. all numbers, or all strings, or all "compatible" tuples.
Or do you think a dictionary should also be constrained to have keys that are all comparable with each other (i.e., presumably, never both string AND number keys) as well as hashable?
If you know *nothing* about the keys of a dict, you already have to do that if you want to sort the keys. There are lots of apps that have no need to ever sort the keys: if there weren't, it would have been wiser to keep the keys in sorted order in the first place, like ABC did.
I fail to see how forbidding me to sort the list of keys of any arbitrary dict will enhance my productivity in any way -- it's bad enough (in theory -- in practice it doesn't bite much as complex numbers are used so rarely) with the complex numbers thingy, why make it even worse by inventing a novel "strings vs numbers" split?
To the contrary, I don't see how it will reduce your productivity. You seem to be focusing on the wrong thing (sorting dict keys). The right thing to consider here is that "a < b" should only work if a and b can be meaningfully ordered, just like "a + b" only works if a and b can be meaningfully added.
Since when is Python about forbidding the user to do quite normal things such as sorting the list of keys of any arbitrary dictionary for more elegant display -- for no practically useful purpose that I've ever seen offered, in brisk violation of "practicality beats purity"?
I doubt that elegant display of a dictionary with wildly incompatible keys is high on anybody's list of use cases. On the other hand, I'm sure that raising an exception on abominations like 2 < "1" or (1, 2) < 0 is a good thing, just like we all agree that forbidding 1 + "2" is a good thing. Of course, == and != will continue to accept objects of incongruous types -- these will simply be considered inequal. That's the cornerstone of dictionaries, and I see no reason to change this -- while I don't know whether 1 ought to be considered less than or greater than 1j, I damn well know they aren't equal! (And I'm specifically excluding gray areas like comparing tuples and lists. Given that (a, b) = [1, 2] now works, as does [].extend(()), it might be better to allow comparing tuples to lists, and even consider them equal if they have the same length and their items compare equal pairwise. This despite my position about the different idiomatic uses of the two types. And so the circle closes [see Subject]. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)