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 interface away (just as
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 i
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 that I think is impor
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 perfectly valid code
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 at
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 the
> current heapq mo
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 ne
On 22 November 2017 at 11:00, 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*.
>
> I don't think there's any reason to have *both
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,
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 compatibil
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
> time to bind them together
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 on a list? I think heapq.heapify is the answer:
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
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
> > >
> > I still think the heapq.heap* functions
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 place*.
>
>
> There's no reaso
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
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 still think the heapq.heap* functions are
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 packaged with *no add
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 the line of
https:/
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.
On
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 cray-cray".)
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 up multiple times.
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 "heapsomething", and basi
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
type
24 matches
Mail list logo
