[Python-Dev] Re: lists v. tuples

[Chermside, Michael]

[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