[Patches] [ python-Patches-866594 ] heapq: A way to change the compare function

SourceForge.net noreply at sourceforge.net
Thu Jan 1 02:49:09 EST 2004


Patches item #866594, was opened at 2003-12-28 12:06
Message generated for change (Comment added) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Raymond Hettinger (rhettinger)
Summary: heapq: A way to change the compare function

Initial Comment:
It'd be nice if heapq could use a custom compare function.
This way the user won't need to write a class with <=
method.

I've added set_cmp(cmp=None) for setting the
comparision function. Using cmp and not expliclty <=
makes later changes in implementation easier.

Attached are the diffs.

BTW: I know in CVS heapq is a C module now, don't have
the  time to change my patch...

Miki


----------------------------------------------------------------------

>Comment By: Miki Tebeka (tebeka)
Date: 2004-01-01 09:49

Message:
Logged In: YES 
user_id=358087

Also just giving a "lambda" is much shorter than writing a
class with __cmp__ which only servers for comparison.

I agree that this is a lame patch but in the current design
of heapq (using build-in lists) the only other solution I
see is to add another "compare" parameter to the module's
functions (e.g. def heappop(heap, compare=None): ...). If
this is acceptable I'll submit a patch.

The other way is to create a new heap object which will be a
subclass of list and will have a "compare" property.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-01 00:54

Message:
Logged In: YES 
user_id=80475

There is no shortage of use cases -- sometimes top priorities 
have higher numbers -- the use cases are basically the same 
as those for descending sorts.

The proposed solution must be rejected because the global 
variable would be shared among all modules using heapq.  It 
is possible the one module relies on __le__ while other 
modules might prefer __ge__.  Those modules could be used 
at the same time.

If a non-global solution is found, please re-submit.



----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2003-12-29 16:53

Message:
Logged In: YES 
user_id=99874

Can you explain better the motivation for adding this? I don't 
find writing __le__() to be a significant problem normally, and 
setting the global _le seems a less-than-perfect design. What 
is a use case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470



More information about the Patches mailing list