Guido rethinking removal of cmp from sort method

[Ian Kelly]

On Thu, Mar 24, 2011 at 10:47 AM, Antoon Pardon
<Antoon.Pardon at rece.vub.ac.be> wrote:
>> 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.

False.  He asked for either sort of case:

> If anyone has any use-cases for sorting with a comparison function that
> either can't be written using a key function, or that perform really
> badly when done so, this would be a good time to speak up.


> You then responded, that you could solve that by sorting in multiple
> steps.

No, I did not.

> 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.

That is a perfectly reasonable argument that you apparently were too
lazy to even mention before.  It is completely different from and not
at all implied by the patently absurd statement "So this list is
sorted within the class but how it is sorted is decided outside the
class. So I can't do the sort in multiple steps."

I would not say "The sky is green" when what I mean is "The color of
the sky is the result of the atmosphere scattering the white light
from the sun in the smaller wavelengths, including some green light."
Would you?

> 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])

I misunderstood your use case, then.  When you wrote that "how it is
sorted is decided outside of the class" in the context of sorting
based on multiple keys, I took that to imply that the external code
was deciding the sorting at runtime, e.g. that perhaps your priority
queue was being displayed in a GUI table that can be sorted on
multiple columns simultaneously.  But evidently you expect that this
key-based sort order will always be hard-coded?

> 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.

On the other hand, if at some point your library really does need to
accept a dynamically generated sort order, then you are pushing the
complexity onto the client code by forcing it to generate a cmp
function like the one I posted above.  But perhaps that will never be
the case for your purpose, in which case I take your point.