[Python-ideas] Adding a thin wrapper class around the functions in stdlib.heapq
rosuav at gmail.com
Tue Nov 21 20:00:37 EST 2017
On Wed, Nov 22, 2017 at 11:45 AM, Steven D'Aprano <steve at pearwood.info> 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 <srkunze at mail.de> 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
> 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
> 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:
> function(value, arguments)
> then that's a difference that makes no difference, and there is no
> advantage to using an object wrapper.
> See also:
> 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
from heaps import Heap
h = Heap()
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.
More information about the Python-ideas