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.je...@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 <ncogh...@gmail.com> wrote: > >> On 22 November 2017 at 11:00, Chris Angelico <ros...@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 | ncogh...@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/ >> >> > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
