[Python-Dev] Re: lists v. tuples (original) (raw)

Chermside, Michael mchermside@ingdirect.com
Mon, 17 Mar 2003 08:50:22 -0500

[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=20 or display the keys should presumably do the sorting within a try/except? [...] 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?

[Guido van Rossum]

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. =20 If you know nothing about the keys of a dict, you already have to do that if you want to sort the keys. =20 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.

Actually, I found Alex's example to be quite persuasive. I had been reading this thread and thinking how I essentially never create and sort lists containing mixed arbitrary objects. But I DO use dicts, and while most of my dicts have string-only keys, there are others that don't.

I wouldn't want to maintain the keys in sorted order, because I don't have to sort my dictionaries (at least the ones that have mixed arbitrary objects for keys), EXCEPT that I DO sort them when I'm debugging! It's a pain (as I'm sure you know) to examine two dicts in a logfile or debug session and find how they differ, a task made much easier by sorting the keys before listing.

So Alex convinced me that I DO have a use-case for sorting arbitrary things after all... in code (like my dict prettifier) used for coding and debugging. And if I ever used complex numbers in my lists, I'd already be in trouble... but somehow it's never come up. (I guess complex #s as keys are unusual ;-).)

I think the lesson is that we shouldn't break arbitrary object comparison (more than it's already broken) until AFTER Guido's OTHER proposal (the "before()" comparison) is in place to be used in this sort of situation. I wouldn't mind switching over to a slightly different syntax as long as I don't have to write a custom sort routine each and every time I want to print a dict to the logs.

[Guido van Rossum]

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.

I agree with you there!

-- Michael Chermside