Nilton Volpato added the comment:
Nice!
Maybe we could add the decorate/undecorate step to guarantee stability
to the C implementation. I'll do some experiments and timings on this.
The heapq library has a lot of room for optimization, I think.
___
Python tr
Raymond Hettinger added the comment:
After looking at the ugly handling of this logic in the 3.0 translation,
I've reconsidered. It is better to have a separate path for the case
where the key is None. See r68095 and r68096 .
--
resolution: rejected -> accepted
__
Raymond Hettinger added the comment:
Am rejecting the patch because it violates the sort equivalence
guarantee (including sort's promise to maintain stability).
If you need the speed and don't care about sort stability, then just use
_heapq.nsmallest() or _heapq.nlargest() directly.
We could c
New submission from Nilton :
The wrapper around heapq.nlargest and heapq.nsmallest is much slower
than it's C version.
$ python2.5 -mtimeit -s 'import random; random.seed(123); n=99;
x=range(n); random.shuffle(x); import _heapq' '_heapq.nlargest(3, x)'
10 loops, best of 3: 142 msec per loop
