Guido rethinking removal of cmp from sort method

[Dan Stromberg]

On Mon, Mar 28, 2011 at 10:11 PM, Dan Stromberg <drsalists at gmail.com> wrote:

>
> On Mon, Mar 28, 2011 at 6:58 PM, Paul Rubin <no.email at nospam.invalid>wrote:
>
>> DSU is a clever and useful design pattern, but comparison
>> sorting is what all the sorting textbooks are written about.
>>
>
> Actually, even though I wrote one program that could almost benefit from
> cmp sorting that might have trouble with key sorting, I think it was
> probably the right decision to remove cmp sorting.
>

I must (partially) recant this.  It's not clear to me this was a good
decision.

Key sorting gives a nice performance boost (because it frequently allows a
sort to be run without any calls to python code), but it's not a complete
replacement for cmp sorting because cmp sorting does not require exposing
implementation detail (at least, not without some foresight and extra
typing) to a module's client.

I like fast, but not so much that I think we should make abstractions
impure.

I don't care that much about modifying code across 2.x to 3.x, but modifying
client code now and then in 3.x because of a misfeature - that bothers me.

If we must have just one, cmp sorting is probably better - just for code
beauty.

I'm not sure having both would be a bad thing really.  They seem distinct
enough from one another, as well as complementary enough, that IMO it'd be
justified.  It strikes me as "there's more than one way to do it" only if
you define "it" rather broadly.

On the other hand...  What if the key function were to become something
other than a callable?  Like a tuple of (list.use_cmp_fn, cmp_fn)?  It's
ugly, but it'd allow you to have the fast sorting normally, and fall back on
something more general when the need surfaces - without requiring a change
in client code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110401/b9b83f4f/attachment-0001.html>