bearophile:
> I don't like your solution, this class was already slow enough. Don't
> use unbound methods with this class :-)
Sorry for raising this discussion after so much time. Another possibile
solution is to use the normal methods for the normal case, and replace
them only if key is present (
Steven Bethard <[EMAIL PROTECTED]> writes:
> Heap(sequence=None, inplace=False)
> KeyedHeap(key, sequence=None)
> Of course, this approach ends up with a bunch of code duplication again.
Maybe there's a way to use a metaclass that can make either type of
heap but they'd share most method
[EMAIL PROTECTED] wrote:
> Steven Bethard wrote:
>> The current code fails when using unbound methods however::
>
> I don't like your solution, this class was already slow enough. Don't
> use unbound methods with this class :-)
> Maybe there's a (better) solution to your problem: to make Heap a
>
Steven Bethard wrote:
> The current code fails when using unbound methods however::
I don't like your solution, this class was already slow enough. Don't
use unbound methods with this class :-)
Maybe there's a (better) solution to your problem: to make Heap a
function (or classmethod) that return
[EMAIL PROTECTED] wrote:
> Steven Bethard:
>> Antoon Pardon:
>>> For me, your class has the same drawback as the heappush, heappop
>>> procedurers: no way to specify a comparision function.
>> Agreed. I'd love to see something like ``Heap(key=my_key_func)``.
>
> It can be done, but the code becom
On 2007-01-18, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Neil Cerutti:
>> One more idea, cribbed from the linked list thread elsewhere:
>> it might be nice if your Heap could optionally use an
>> underlying collections.deque instead of a list. I don't know
>> how excellent Python's deque is, b
On 2007-01-18, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Neil Cerutti:
>> One more idea, cribbed from the linked list thread elsewhere:
>> it might be nice if your Heap could optionally use an
>> underlying collections.deque instead of a list. I don't know
>> how excellent Python's deque is, b
Neil Cerutti:
> One more idea, cribbed from the linked list thread elsewhere: it
> might be nice if your Heap could optionally use an underlying
> collections.deque instead of a list.
> I don't know how excellent Python's deque is, but it's possible a
> deque would provide a faster heap than a cont
Steven Bethard:
> Antoon Pardon:
> > For me, your class has the same drawback as the heappush, heappop
> > procedurers: no way to specify a comparision function.
>
> Agreed. I'd love to see something like ``Heap(key=my_key_func)``.
It can be done, but the code becomes more complex and hairy:
http
Antoon Pardon wrote:
> For me, your class has the same drawback as the heappush, heappop
> procedurers: no way to specify a comparision function.
Agreed. I'd love to see something like ``Heap(key=my_key_func)``.
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
On 2007-01-16, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Scott David Daniels:
>> I'd suggest some changes. It is nice to have Heaps with equal
>> contents equal no matter what order the inserts have been
>> done. Consider how you want Heap([1, 2, 3]) and Heap([3, 1,
>> 2]) to behave. Similarl
On 2007-01-16, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> In few minutes I have just written this quite raw class, it lacks
> doctring (the same of the functions of the heapq module), it may
> contain bugs still, I haven't tested it much. It's just a simple
> wrapper around some of the function
Scott David Daniels:
> I'd suggest some changes. It is nice to have Heaps with equal
> contents equal no matter what order the inserts have been done.
> Consider how you want Heap([1, 2, 3]) and Heap([3, 1, 2]) to behave.
> Similarly, it is nice to have str and repr produce canonical
> representat
Scott David Daniels wrote:
Sorry, I blew the __ne__:
>> def __ne__(self, other):
>> return not isinstance(other, Heap) or self.h != other.h
> return not isinstance(other, self.__class__) and sorted(
> self.h) != sorted(other.h)
Should be:
[EMAIL PROTECTED] wrote:
> In few minutes I have just written this quite raw class,
I'd suggest some changes. It is nice to have Heaps with equal
contents equal no matter what order the inserts have been done.
Consider how you want Heap([1, 2, 3]) and Heap([3, 1, 2]) to behave.
Similarly, it
[EMAIL PROTECTED] kirjoitti:
> I think the sort has to be simplified, otherwise it can't keep the heap
> invariant...
>
> def sort(self):
> self.h.sort()
>
> Bye,
> bearophile
>
And __repr__ should be something like this:
=
def __repr__(self):
if self.h:
re
I think the sort has to be simplified, otherwise it can't keep the heap
invariant...
def sort(self):
self.h.sort()
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> some time ago I have written a bug
> into small program that uses the functions of the heapq module, because
> I have added an item to the head of the heap using a normal list
> method, breaking the heap invariant.
I know I've had similar bugs in my code before.
> from
In few minutes I have just written this quite raw class, it lacks
doctring (the same of the functions of the heapq module), it may
contain bugs still, I haven't tested it much. It's just a simple
wrapper around some of the functions of the heapq module (nsmallest and
nlargest are missing). Usually
19 matches
Mail list logo
