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

Nick Timkovich prometheus235 at gmail.com
Wed Nov 22 01:22:00 EST 2017

On Tue, Nov 21, 2017 at 6:45 PM, Steven D'Aprano <steve at pearwood.info>

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

Probably straining the reference, but akin to "don't teach JSON with
Python, teach XML-RPC because it supports that better in the stdlib", why
not "don't teach heaps, just use lists with pop and insert+sort".

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

Functions are great. I'm a big fan of functions. However,

1. Once there are several that all have the same thing as an argument:
thing_operation1(thing, arg), thing_operation2(thing, arg)...it's about
time to bind them together.
2. And especially for the heap "soft-datatype": once it's heapified,
naively modifying it with other methods will ruin the heap invariant. **The
actual list you pass around can't be treated as a list.**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171122/eb8cac71/attachment.html>

More information about the Python-ideas mailing list