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

[bunslow]

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

I've never used bisect, so I'll refrain from commenting on it.

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.

On Wed, Nov 22, 2017 at 11:11 PM, Grant Jenks <grant.jenks at gmail.com> wrote:

> 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/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 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/
>>
>>
>
> _______________________________________________
> 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/51388325/attachment.html>