[Python-Dev] Re: lists v. tuples

[Guido van Rossum]

[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/)