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

On 23 November 2017 at 17:13, Grant Jenks wrote: > And it will work! The heap algorithm is exposed through a high-level > functional interface so that you can take advantage of duck-typing. This is > an important Python feature. > Nobody is proposing taking the functional

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

Grant Jenks wrote: The heap algorithm is exposed through a high-level functional interface so that you can take advantage of duck-typing. This would also be true of a HeapWrapper class that wrapped an existing sequence. There's a difference between the heap functions and sorted(). The latter

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

On Wed, Nov 22, 2017 at 9:22 PM, bunslow wrote: > Something *should* be object oriented with the functions in question all > operate on the same data type, and in particular, those functions/verbs > *are only well defined for that type*. > But here you are missing something

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

On 23 November 2017 at 15:22, bunslow wrote: > Something *should* be object oriented with the functions in question all > operate on the same data type, and in particular, those functions/verbs > *are only well defined for that type*. heapq.heappush(list-not-heap, item) > is

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

Something *should* be object oriented with the functions in question all operate on the same data type, and in particular, those functions/verbs *are only well defined for that type*. heapq.heappush(list-not-heap, item) is perfectly valid code in the current interface, but doesn't make any sense

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

On Wed, Nov 22, 2017 at 10:52 PM, bunslow wrote: > I'll just note the original proposal I made was specifically designed to > be the minimum possible improvement, to avoid controversy (and e.g. a PEP). > > I agree that there are significant flaws and room for improvement in

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

Honestly, I don't see the value in a thin object-oriented wrapper around heapq functions. I'm a big -1 on the idea. I'm the author of sortedcontainers ( https://pypi.python.org/pypi/sortedcontainers/) so I interact with a lot of people using sorted collections types. My observations show folk's

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

Chris Angelico wrote: Yeah but if it's wrapping an existing list, it's not really constructing a new object. That depends on what you consider the object to be. There are existing examples of objects that wrap other objects and mutate them, e.g. TextIOWrapper. If it would make anyone happier,

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

I thought the purpose of heapq was to have a ready-made example for instructors on how an API can be improved by applying object-oriented techniques. ;-) I think adding a HeapQueue class would be a great idea. Obviously the existing functions would need to continue existing for backward

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

On Wed, 22 Nov 2017 00:22:00 -0600 Nick Timkovich wrote: > > 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 >

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

On Wed, 22 Nov 2017 17:11:53 +1100 Chris Angelico wrote: > On Wed, Nov 22, 2017 at 3:55 PM, Greg Ewing > wrote: > > Chris Angelico wrote: > >> > >> So the question is more: why, with Python being the way it is, do the > >> heap functions operate

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

On 22.11.2017 07:22, Nick Timkovich wrote: 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

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

On Tue, Nov 21, 2017 at 6:45 PM, Steven D'Aprano 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 wrote: > > > > > Maybe, that suffices: https://pypi.python.org/pypi/xheap > > > > >

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

On Wed, Nov 22, 2017 at 3:55 PM, Greg Ewing wrote: > Chris Angelico wrote: >> >> 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

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

Chris Angelico wrote: 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*. There's no reason a Heap object couldn't accomodate that case. E.g. the constructor

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

On Wed, Nov 22, 2017 at 11:45 AM, Steven D'Aprano 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 wrote: >> >> > Maybe, that suffices: https://pypi.python.org/pypi/xheap >> > >> I

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

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 wrote: > > > Maybe, that suffices: https://pypi.python.org/pypi/xheap > > > I still think the heapq.heap* functions are atrocious and they should > immediately be

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

On Tue, Nov 21, 2017 at 4:16 PM, Sven R. Kunze 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

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

Maybe, that suffices: https://pypi.python.org/pypi/xheap On 21.11.2017 03:46, bunslow wrote: Perhaps such repetition is a sign that *something* needs to be done... Thanks for the link though. I'm new enough to the community that it didn't even occur to me to search for prior discussions.

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

bunslow writes: > Perhaps such repetition is a sign that *something* needs to be > done... It's not. Most such repetition is due to new people who have not read the last 20 years of archives. :-) (In case the smiley isn't clear enough, parse that as "all the new people who aren't

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

Perhaps such repetition is a sign that *something* needs to be done... Thanks for the link though. I'm new enough to the community that it didn't even occur to me to search for prior discussions. On Mon, Nov 20, 2017 at 8:38 PM, Sebastian Kreft wrote: > This has been brought

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

This has been brought up multiple times. Last time was on this thread https://mail.python.org/pipermail/python-ideas/2016-October/043024.html. On Tue, Nov 21, 2017 at 3:13 AM, bunslow wrote: > Nothing so bombastic this time. The heapq functions are basically all > named

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

Nothing so bombastic this time. The heapq functions are basically all named "heapsomething", and basically all take a "heap" for their first argument, with supplementary args coming after. It's a textbook example of the (hypothetical) Object Oriented Manifesto™ where defining a class increases