On Tue, Nov 21, 2017 at 6:45 PM, Steven D'Aprano <steve@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@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.**