On Wed, Nov 22, 2017 at 10:52 PM, bunslow wrote:

I'll just note the original proposal I made was specifically designed to be the minimum possible improvement, to avoid controversy (and e.g. a PEP).

I agree that there are significant flaws and room for improvement in the current heapq module (which is why things like xheap exist), but even so it's still very useful as is, and the minimal OOP wrapper would go a long way towards usability of the current functionality (and of course "just use pip" is often not a viable course of action for certain developers). It seems that such a wrapper is widely (though not unanimously) approved.

Next step I suppose is creating a bpo issue?

On Wed, Nov 22, 2017 at 10:05 PM, Nick Coghlan wrote:

...

On 22 November 2017 at 11:00, Chris Angelico wrote:

...

So the question is more: why, with Python being the way it is, do the heap functions operate on a list? I think heapq.heapify is the answer: in linear time, it heapifies a list *in place*.

I don't think there's any reason to have *both* interfaces to the heap functionality, but it certainly isn't illogical to try to treat a heap as a thing, and therefore have a Heap type.

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. https://code.activestate.com/r ecipes/577197-sortedcollection/ then provides an example of how to combine those into a "SortedCollection" type.

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:

- it makes it easier to reliably maintain the heap invariant (just drop your list reference after passing it to the heap wrapper) - it gives both human readers and static code analysers more information to work with ("this is a heap" rather than "this is a list") - it provides a hook for improved interactive help on heap instances

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.

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).

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/