Guido rethinking removal of cmp from sort method

[Antoon Pardon]

On Thu, Mar 24, 2011 at 09:06:44AM -0600, Ian Kelly wrote:
> On Thu, Mar 24, 2011 at 3:23 AM, Antoon Pardon
> <Antoon.Pardon at rece.vub.ac.be> wrote:
> > Sure I can do that. I can do lots of things like writing a CMP class
> > that I will use as a key and where I can implement the logic for
> > comparing the original objects, which I otherwise would have put in a
> > cmp function. I thought this wasn't about how one can get by without
> > the cmp argument. This was about cases where the cmp argument was the
> > more beautiful or natural way to handle this case.
> 
> That's not what you wrote before.  You wrote "I can't do the sort in
> multiple steps."  I was just responding to what you wrote.

That is because I tend to assume some intelligence with those I
communicate with, so that I don't need to be pedantly clear and
spell everything out.

However since that seems to be a problem for you I will be more
detailed. The original poster didn't ask for cases in which cmp
was necessary, he asked for cases in which not using cmp was
cumbersome. I gave a case where not using cmp was cumbersome.
a tuple where you want it sorted with first item in descending
order and second item ascending.

You then responded, that you could solve that by sorting in multiple
steps. The problem with this response is that how items are to be
compared can be decided in a different module from where they are
actually sorted. So if we would accept this MO, this would mean
that any module that needed to sort something according to a provided
key, would need to provide for the possibility that the sorting would
have to be done in multiple steps. So, in order to avoid complexity
in the internal python sort, we would increase the complexity of
all library code that would need to sort things in a by the user
provided way and didn't want to barf in such an event.

So when I wrote I couldn't do that, I implicitly meant if you
want a less cumbersome solution than using cmp, because your
solution would make all library code more cumbersome.

> > I think I have provided such a case. If you don't agree then
> > don't just give examples of what I can do, argue how your solution
> > would be a less ugly or more natural way to handle this.
> 
> Well, the alternative is to generate the cmp function from the
> externally selected keys dynamically at runtime, is it not?  Something
> like this:
> 
> def get_cmp(keys):
>     def cmp(a, b):
>         for (key, reversed) in keys:
>             if reversed:
>                 result = cmp(key(b), key(a))
>             else:
>                 result = cmp(key(a), key(b))
>             if result != 0:
>                 return result
>         return result
>     return cmp
> 
> I fail to see how that is any more natural than my solution, unless
> you have another way of doing it.  And it's certainly not going to be
> any faster.

First of all, there is no need for a dynamical generated cmp function in
my provided case. My cmp fumction would simply look like this:

def cmp(tp1, tp2):
  return cmp(tp2[0], tp1[0]) or cmp(tp1[1], tp2[1])

Second, there is not only the question of what is more natural, but
there is also the question of how you are spreading the complexity.
Your first solution would mean spreading the complexity to all library
code where the user could provide the order-relation of the items that
would then be sorted within the library. This alternative of your, even
if too complicated than needed would mean that libary code could just
use the sort method and the complicated code is limited to those
specific items that need it.

-- 
Antoon Pardon