On Wed, Nov 22, 2017 at 11:45 AM, Steven D'Aprano email@example.com wrote:
On Tue, Nov 21, 2017 at 04:56:27PM -0600, Nick Timkovich wrote:
On Tue, Nov 21, 2017 at 4:16 PM, Sven R. Kunze firstname.lastname@example.org wrote:
Maybe, that suffices: https://pypi.python.org/pypi/xheap
I still think the heapq.heap* functions are atrocious and they should immediately be packaged with *no additional features* into a stdlib object for reasons along the line of https://mail.python.org/pipermail/python-ideas/2017-October/047514.html
I think you pasted the wrong URL. That link is about pip, and the discoverability of third-party libraries. It says nothing about why functions are "atrocious" and why wrapping them into an object is better.
But generally, Python's APIs are not "pure object oriented" in the Java sense, and we don't needlessly create objects just for the sake of ensuring everything is an object. Functions are fine too, and if the only difference between a function and method is the syntax you use to call it:
then that's a difference that makes no difference, and there is no advantage to using an object wrapper.
for a perspective on how the emphasis on objects is harmful.
What advantage is there to making the heap functions into Heap methods?
A heap is an actual thing. We don't have dict methods implemented as functions operating on a "blob of memory" object; we have dict as a type. So the most simple and obvious way to work with a heap would be something like:
from heaps import Heap
h = Heap() h.push(blah) h.pop()
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.