<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 November 2017 at 11:00, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So the question is more: why, with Python being the way it is, do the<br>
heap functions operate on a list? I think heapq.heapify is the answer:<br>
in linear time, it heapifies a list *in place*.<br>
<br>
I don't think there's any reason to have *both* interfaces to the heap<br>
functionality, but it certainly isn't illogical to try to treat a heap<br>
as a thing, and therefore have a Heap type.<br></blockquote><div><br></div>Right, the parallel here is that we have a "heapq" module for the same reason that we have list.sort(), sorted(), and the bisect module, rather than a single "SortedList" type. <a href="https://code.activestate.com/recipes/577197-sortedcollection/">https://code.activestate.com/recipes/577197-sortedcollection/</a> then provides an example of how to combine those into a "SortedCollection" type.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">That said, I'm still in favour of adding an object-oriented wrapper to either `collections` or the `heapq` module for all the classic OO reasons:</div><div class="gmail_quote"><br></div><div class="gmail_quote">- it makes it easier to reliably maintain the heap invariant (just drop your list reference after passing it to the heap wrapper)</div><div class="gmail_quote">- it gives both human readers and static code analysers more information to work with ("this is a heap" rather than "this is a list")</div><div class="gmail_quote">- it provides a hook for improved interactive help on heap instances</div><div class="gmail_quote"><br></div><div class="gmail_quote">I don't have any great concerns about potential confusion - the OO wrapper will be easy enough to use that anyone that's unsure will likely gravitate towards that, while the lower level `heapq` functions will remain available for folks writing their own heap implementations.</div><div class="gmail_quote"><br></div><div class="gmail_quote">This effect would likely be even more pronounced if the OO wrapper were made available as `collections.Heap` (`collections` already imports the `heapq` module for use in the Counter implementation).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.<br></div><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>