Message213365
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=. |
|
Date |
User |
Action |
Args |
2014-03-13 08:59:55 | gdr@garethrees.org | set | recipients:
+ gdr@garethrees.org, Prashant.Sharma |
2014-03-13 08:59:55 | gdr@garethrees.org | set | messageid: <1394701195.67.0.156316765205.issue20905@psf.upfronthosting.co.za> |
2014-03-13 08:59:55 | gdr@garethrees.org | link | issue20905 messages |
2014-03-13 08:59:54 | gdr@garethrees.org | create | |
|