Gareth Rees added the comment:
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=.
----------
nosy: +Gareth.Rees
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue20905>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
