Why keep identity-based equality comparison?

Antoon Pardon apardon at forel.vub.ac.be
Thu Jan 12 09:59:23 EST 2006


Op 2006-01-12, Paul Rubin schreef <http>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>> The bisect module doesn't have an alternate comparison function
>> neither has the heapqueue module.
>
> They could be extended.  Care to enter a feature request?

Not really because IMO this is the wrong approach.

>> 1) Python could provide a seperare total ordering, maybe with operators
>>    like '<|' and '|>' and function operator.rank (with functionlity
>>    similar to cmp)
>
> Based on experience that I'm sure you understand, anything like that
> is going to be awfully hard to sell.
>
>> 3) Python could provide the possibility of providing an alternate
>>    comparison function with heapqueue, bisect and similar modules.
>
> That's probably the best bet.

But IMO not very helpfull. When I use a heapqueue I need to use
it with the same comparison function through its whole lifetime.
It doesn't make sense to work with a heapqueue that has a variable
comparison function. So having to provide this comparison function
with each operation strikes me as much to cumbersome and error prone.
Especially if you are working with multiple heaps each with its
own comparison function.

Writing my own heapqueue class that takes a comparison function as
a parameter to the __init__ method to associate with that particular
heapqueue seems a more rational solution than extending (or letting
others do so) the stdlib packages with such a parameter.

IMO letting python associate such a function with an arbitrary container
is the most usefull option. It would allow the programmer to easily define
what they need.

Do you only care about identity, provide a comparison function that
works on identy.

Do you want lst.index(1) to return the index of 1.0 and decimal("1")
or not. You would be able to specify this just how you want by
just associating a new comparison function with the container.

Now off course I could write a subclass of list which would do
all this, but that would mean writing a lot of the functionality
that is basically already there.

-- 
Antoon Pardon



More information about the Python-list mailing list