[Python-ideas] Adding a thin wrapper class around the functions in stdlib.heapq

[Sven R. Kunze]

Maybe, that suffices: https://pypi.python.org/pypi/xheap


On 21.11.2017 03:46, bunslow wrote:
> Perhaps such repetition is a sign that *something* needs to be done...
>
> Thanks for the link though. I'm new enough to the community that it 
> didn't even occur to me to search for prior discussions.
>
> On Mon, Nov 20, 2017 at 8:38 PM, Sebastian Kreft <skreft at gmail.com 
> <mailto:skreft at gmail.com>> wrote:
>
>     This has been brought up multiple times. Last time was on this
>     thread
>     https://mail.python.org/pipermail/python-ideas/2016-October/043024.html
>     <https://mail.python.org/pipermail/python-ideas/2016-October/043024.html>.
>
>     On Tue, Nov 21, 2017 at 3:13 AM, bunslow <bunslow at gmail.com
>     <mailto:bunslow at gmail.com>> wrote:
>
>         Nothing so bombastic this time. The heapq functions are
>         basically all named "heapsomething", and basically all take a
>         "heap" for their first argument, with supplementary args
>         coming after. It's a textbook example of the (hypothetical)
>         Object Oriented Manifesto™ where defining a class increases
>         type safety and programmers' conceptual clarity. There're
>         practically no drawbacks, and the code to be added would be
>         very simple. Updating the tests and docs would probably be
>         harder.
>
>         In pure Python, such a class would look like this:
>
>         class Heap(list):
>
>             def __init__(self, iterable=None):
>                 if iterable:
>                     super().__init__(iterable)
>                 else:
>                     super().__init__()
>
>                 self.heapify()
>
>             push = heapq.heappush
>             pop = heapq.heappop
>             pushpop = heapq.heappushpop
>             replace = heapq.heapreplace
>             heapify = heapq.heapify
>
>             # This could be a simple wrapper as well, but I had the
>         following thoughts anyways, so here they are
>             def nsmallest(self, n, key=None):
>                 # heapq.nsmallest makes a *max* heap of the first n
>         elements,
>                 # while we know that self is already a min heap, so we can
>                 # make the max heap construction faster
>                 self[:n] = reversed(self[:n])
>                 return heapq.nsmallest(n, self, key)
>
>             # do we define nlargest on a minheap??
>
>
>         Wrapping around the C builtin functions (which aren't
>         descriptors) would be a bit harder, but not much so:
>
>         from functools import partial
>
>         class Heap(list):
>             def __init__(self, iterable=None):
>                 if iterable:
>                     super().__init__(iterable)
>                 else:
>                     super().__init__()
>
>                 self.heapify = partial(heapq.heapify, self)
>                 self.push = partial(heapq.heappush, self)
>                 ...
>
>                 self.heapify()
>
>
>         Thoughts?
>
>         _______________________________________________
>         Python-ideas mailing list
>         Python-ideas at python.org <mailto:Python-ideas at python.org>
>         https://mail.python.org/mailman/listinfo/python-ideas
>         <https://mail.python.org/mailman/listinfo/python-ideas>
>         Code of Conduct: http://python.org/psf/codeofconduct/
>         <http://python.org/psf/codeofconduct/>
>
>
>
>
>     -- 
>     Sebastian Kreft
>
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171121/a4a8327d/attachment-0001.html>