It would be better to accept a key function instead of a comparison
function (cf. heapq.nlargest and heapq.nsmallest).

But note that this has been proposed before and rejected: see
issue1904 where Raymond Hettinger provides this rationale:

    Use cases aside, there is another design issue in that the
    key-function approach doesn't work well with the heap functions on
    regular lists. Successive calls to heap functions will of
    necessity call the key- function multiple times for any given
    element. This contrasts with sort () where the whole purpose of
    the key function was to encapsulate the decorate-sort-undecorate
    pattern which was desirable because the key- function called
    exactly once per element.

However, in the case of the bisect module (where requests for a key
function are also common), Guido was recently persuaded that there was
a valid use case. See issue4356, and this thread on the Python-ideas
mailing list:
<https://mail.python.org/pipermail/python-ideas/2012-February/thread.html#13650>
where Arnaud Delobelle points out that:

    Also, in Python 3 one can't assume that values will be comparable so
    the (key, value) tuple trick won't work: comparing the tuples may well
    throw a TypeError.

and Guido responds:

    Bingo. That clinches it. We need to add key=.