<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 November 2017 at 15:22, bunslow <span dir="ltr"><<a href="mailto:bunslow@gmail.com" target="_blank">bunslow@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">Something *should* be object oriented with the functions in question all operate on the same data type, and in particular, those functions/verbs *are only well defined for that type*. heapq.heappush(list-not-heap, item) is perfectly valid code in the current interface, but doesn't make any sense at all. And list.sort is *not* function based, it's an object oriented method. sorted() provides the same functionality for other types, given that it's a well defined function for a wide variety of sequences (unlike heappush). (list.sort is a method because unlike sorted(), it operates inplace, and is thus only meaningful for mutable, "complete" (all in memory, not "lazy") sequences -- i.e., a list.)<div><br></div><div>I've never used bisect, so I'll refrain from commenting on it.</div><div><br></div><div>At the end of the day, the patch proposed is merely a wrapper around the functional approach; you are welcome to continue using it as you like, it's not going anywhere. I would propose that the docs put the OOP version first though.</div></div></blockquote><div><br></div>Ensuring the docs are clearly separated is part of why I think "collections.Heap" would make more sense as a proposal than "heapq.Heap" - collections already imports heapq for use in the Counter implementation, and adding another primitive container type to collections is a smaller conceptual change than updating heapq to being more than just a heap algorithm library.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I'd also note that a collections.Heap class that accepts the underlying list to use as its sole parameter would compose nicely with the list builtin to allow creation of a heap from an arbitrary iterable:</div><div class="gmail_quote"><br></div><div class="gmail_quote">    heap = collections.Heap(list(iterable))</div><div class="gmail_quote"><br></div><div class="gmail_quote">rather than the current:</div><div class="gmail_quote"><br></div><div class="gmail_quote">    heap = list(iterable)</div><div class="gmail_quote">    heapq.heapify(heap)<br></div><div class="gmail_quote"></div><div class="gmail_quote"><br></div><div class="gmail_quote">That's akin to the difference between:</div><div class="gmail_quote"><br></div><div class="gmail_quote">    data = sorted(iterable)</div><div class="gmail_quote"><br></div><div class="gmail_quote">and:</div><div class="gmail_quote"><br></div><div class="gmail_quote">    data = list(iterable)</div><div class="gmail_quote">    data.sort()</div><div class="gmail_quote"><br></div><div class="gmail_quote">I don't think it would be a disaster if we continued to leave this out, but I don't think it would be a major maintenance burden or future barrier to learning to add it, either.<br></div><div class="gmail_quote"></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Nick.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>