On Mon, Mar 28, 2011 at 10:11 PM, Dan Stromberg <drsali...@gmail.com> wrote:
> > On Mon, Mar 28, 2011 at 6:58 PM, Paul Rubin <no.email@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.
-- http://mail.python.org/mailman/listinfo/python-list
