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

[Grant Jenks]

Honestly, I don't see the value in a thin object-oriented wrapper around
heapq functions. I'm a big -1 on the idea.

I'm the author of sortedcontainers (
https://pypi.python.org/pypi/sortedcontainers/) 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.

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.

What I think would be sufficient is a "See also:" blurb like that under
https://docs.python.org/3/library/bisect.html#bisect.insort which also
references SortedContainers at
http://www.grantjenks.com/docs/sortedcontainers/ 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.

Grant


On Wed, Nov 22, 2017 at 8:05 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 22 November 2017 at 11:00, Chris Angelico <rosuav at gmail.com> 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/
> recipes/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 at gmail.com   |   Brisbane, Australia
>
> _______________________________________________
> 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/20171122/28cc707b/attachment.html>