<div dir="ltr">Honestly, I don't see the value in a thin object-oriented wrapper around heapq functions. I'm a big -1 on the idea.<div><br></div><div>I'm the author of sortedcontainers (<a href="https://pypi.python.org/pypi/sortedcontainers/">https://pypi.python.org/pypi/sortedcontainers/</a>) so I interact with a lot of people using sorted collections types. My observations show folk's needs tend to fit a bimodal distribution. At one end are those who get by with list.sort, bisect, or heapq and they seem to appreciate the simple function-based approach those modules provide. At the other end are those who want a SortedList data type and we have some good options on PyPI and some good building-blocks in the standard library.</div><div><br></div><div>Personally, I think "sorted", "bisect" and "heapq" in the standard library are brilliant examples of the Python-way or "zen." I've learned a lot by studying their code and I encourage others to do the same. Just because something can be object-oriented doesn't mean it should be. There's a lot to be said for simplicity. I also think Nick's arguments are valid but I don't find them convincing.</div><div><br></div><div>What I think would be sufficient is a "See also:" blurb like that under <a href="https://docs.python.org/3/library/bisect.html#bisect.insort">https://docs.python.org/3/library/bisect.html#bisect.insort</a> which also references SortedContainers at <a href="http://www.grantjenks.com/docs/sortedcontainers/">http://www.grantjenks.com/docs/sortedcontainers/</a> and the same blurb on heapq. I think that would be a reasonable next-step before we include any new data type in the standard library.</div><div><br></div><div>Grant</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 22, 2017 at 8:05 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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/" target="_blank">https://code.activestate.com/<wbr>recipes/577197-<wbr>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.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><br>-- <br><div class="m_8989610681588590507gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
<br></blockquote></div><br></div>