[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