Guido rethinking removal of cmp from sort method

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sat Mar 26 04:49:42 EDT 2011


On Fri, 25 Mar 2011 16:04:02 -0700, Carl Banks wrote:
> On Mar 25, 3:06 pm, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
> > The reason Guido is considering re-introducing cmp is that somebody at
> > Google approached him with a use-case where a key-based sort did not
> > work. The use-case was that the user had masses of data, too much data
> > for the added overhead of Decorate-Sort-Undecorate (which is what key
> > does), but didn't care if it took a day or two to sort.
> >
> > So there is at least one use-case for preferring slowly sorting with a
> > comparison function over key-based sorting. I asked if there any
> > others. It seems not.

> 1. You asked for a specific kind of use case.  Antoon gave you a use
> case, you told him that wasn't the kind of use case you were asking for,
> then you turn around and say "I guess there are no use cases" (without
> the mentioning qualification).

That is astonishing. Did you read my post before going on the attack? I 
know that there is a grand tradition of adversarial argument on Usenet, 
but I am not your enemy here.

First you wrongly accuse me of stating that there are no use cases, 
without qualification, when the very text you quote has me giving a use-
case. Nor did I say there are no use cases -- I said that I didn't think 
there were any *others*. You even quote me saying this!

Then you go on to wrongly claim:

> 3. You evidently also overlooked the use-case example posted on Python-
> dev that you followed up to.

No, I did not overlook it. I explicitly described it twice. Once in the 
very text you quoted above, and once early in the thread when I wrote:

"Guido himself has mentioned one such good use for a comparison 
function when sorting. Use of a key function trades off memory for time, 
while sorting with a comparison function makes the opposite trade off, 
using more time for the sake of saving memory."


> 2. I posted two use cases in this thread that fit your criteria, and you
> followed up to that subthread so you most likely read them.  Here they
> are again so you won't overlook them this time:
> 
> "You have are given an obscure string collating function implented in a
> C library you don't have the source to."  (Fits your criterion "can't be
> done with key=".)

I must admit I don't understand this use-case. What is a string collating 
function, and what does this have to do with sorting? I could try to 
guess from the plain English meaning of the words, but if I get it wrong, 
that wouldn't be fair to you. Perhaps an example would help.


> "I'm sitting at an interactive session and I have a convenient cmp
> function but no convenient key, and I care more about the four minutes
> it'd take to whip up a clever key function or an adapter class than the
> 0.2 seconds I'd save to on sorting time."  (Fits your criterion
> "performs really badly when done so".)

"I can't be bothered to write a key function" is not equivalent to "I 
have a key function, but it is too slow to use".

In any case, from Python 3.2 onwards, a key function is never more than 
one import and one function call away. (In 3.1, you're stuck writing your 
own adapter, but in 3.1 sort doesn't take a cmp function anyway, so 
either way you're stuck. The earliest it could be reintroduced, if at 
all, is in 3.3.)


> Call me crazy, but you seem to be overlooking a lot of things in your
> zeal to prove your point.

And what point would that be?

Carl, anybody could have asked the question I have asked. Anyone is free 
to summarize the best of the arguments -- or all of them -- and post them 
to python-dev. If you think I have some ulterior motive in doing this, 
please feel free to champion the cmp argument to python-dev instead.



-- 
Steven



More information about the Python-list mailing list