If the equal min y-coords are handled, I think it&#39;d be quicker too. As Guido noted, O(n) function calls is better then O(n log n) =] Though the general case is still unhandled. And, though it doesn&#39;t help my case, the Graham Scan can also be performed on points sorted lexicographically too, by constructing the upper &amp; lower hull separately, hehe.<br>
<br>Now, I understand cmp on the whole was removed from the language. Using __lt__, __eq__, etc. really is more natural. However, having an explicit cmp function for sorting makes sense to me. At the very least, it is more obvious and natural for some problems - though I respect that using a key func. is often faster. In some rare (though &quot;rare&quot; is very subjective) cases it is required; packing a cmp function into __cmp__ in a wrapper object is really just a hard-to-read cmp function and highlights the need for cmp. I would actually love to see it added for min/max too actually, since I find I often use a simple reduce function in place of a min(lst, cmp=...). Enforcing proper comparisons (&lt;, &gt;, ==, etc) makes sense, but would having the cmp function live, so to speak, in sorting really be that bad? Just inform the user in the docs that key is preferred and often faster.<br>