On Tue, Nov 21, 2017 at 6:45 PM, Steven D'Aprano <st...@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 <srku...@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.**
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
