On Tue, Nov 21, 2017 at 6:45 PM, 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
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.**