Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #2183 > unrolled thread

Re: Guido rethinking removal of cmp from sort method

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Guido rethinking removal of cmp from sort method Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-03-29 18:10 +0200

#2183 — Re: Guido rethinking removal of cmp from sort method

Steven D'Aprano wrote:
> On Fri, 25 Mar 2011 10:21:35 +0100, Antoon Pardon wrote:
>
>   
>> On Thu, Mar 24, 2011 at 11:49:53PM +0000, Steven D'Aprano wrote:
>>     
>>> On Thu, 24 Mar 2011 17:47:05 +0100, Antoon Pardon wrote:
>>>
>>>       
>>>> 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'm the original poster, and that's not what I said. I said:
>>>
>>> "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'll notice that I said nothing about whether writing the code was
>>> easy or cumbersome, and nothing about readability.
>>>       
>> Well fine. I should have realised the question was just a pretense and
>> that there really never was any intention to consider the reactions,
>> because the answer is already fixed. Of course a key function can always
>> be written, it may just need a specific class to implement the specific
>> order. Likewise there is no reason to expect the order-functions to
>> preform worse when implemented in a class, rather than in a function.
>>     
>
> 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.
>
>
>   
That was known from the begining, was it ? Since key sort trades memory 
for CPU, you could expect that "masses of data" use cases may fail 
because of memory shortage.

JM

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web