Mark Dickinson added the comment:
Michael: if you want to take this further, your best bet would probably be to
start a discussion on the python-ideas mailing list
(https://mail.python.org/mailman3/lists/python-ideas.python.org/).
--
nosy: +mark.dickinson
Michael Rolle added the comment:
I realize this request is closed, but I hope people will still be reading this
comment, and can perhaps either reopen it or submit a new request. I don't
know how to submit a new request myself.
...
I'd like to see (key=) capability somehow, without
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20905
___
New submission from Prashant Sharma:
It would be more convenient to extend heapq to support user defined
comparators.
Default can be cmp_lt in which case they behave as they do now.
Caveat:
What happens if uses switches comparator between calls to push or pop. The
expected behavior can be
Prashant Sharma added the comment:
Signed the PSF CLA.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20905
___
___
Python-bugs-list mailing
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,
Prashant Sharma added the comment:
Hey Gareth,
add Key= approach also solves the purpose. The purpose is to be able to use
heapq as max heap too conveniently. (I just wish python had minmaxheap too, but
felt that is too much to ask for.) It is a very common usage and usual tricks
of
Mark Lawrence added the comment:
See also #13742.
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20905
___
___
Raymond Hettinger added the comment:
Thanks for submitting a patch.
I'm sorry, but I don't think this is the right approach. I will likely keep
the current functions as they are now. Under no circumstances do I want to add
any overhead to the existing functions (they serve performance
Prashant Sharma added the comment:
Did not knew about #13742. I hope it gets merged soon and may be, if possible
backport too ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20905
___
Prashant Sharma added the comment:
Thanks Raymond for looking at the patch, understood your considerations are
reasonable. This discussion can be closed here.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20905
11 matches
Mail list logo