Why keep identity-based equality comparison?

[Antoon Pardon]

Op 2006-01-11, Mike Meyer schreef <mwm at mired.org>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>> Op 2006-01-11, Mike Meyer schreef <mwm at mired.org>:
>>> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>>>> Op 2006-01-10, Mike Meyer schreef <mwm at mired.org>:
>>>>>> Now you can take the practical option and decide that programmatically
>>>>>> it make no sense to compare a specific couple of values and throw an
>>>>>> exception in this case, but it doesn't matter much which test you are
>>>>>> conducting at that point.
>>>>> Can you provide a case where having a test for equality throw an
>>>>> exception is actually useful?
>>>> I'm not going to bother with that.
>>> Since you're being vague about what you want,
>> I would like some consistency. Either all comparisons between objects
>> of different types throw an exception by default or none does.
>
> That's a very silly thing to ask for. It presumes that all types are
> the same. They aren't.

It doesn't presume anything like that.

> It also presumes that all comparisons are the same. They aren't.

It doesn't presume that either.

> To use an overworked analogy, you might as well ask
> that you either have to peel all fruit, or that you never have to peel
> a fruit.

Bad analogy since a fruit is not a relationship.

> In any case, the proposeed behavior *is* consistent. The behavior for
> all builtin types will be that comparisons that don't make sense will
> throw exceptions.

It is only consistent if you start from an inconsistent view and then
check for how consistently this view is followed. There is nothing
consistent in telling that 1 == (1,3) makes sense and 1 < (1,3)
doesn't make sense. Set theoretically both 1 and (1,3) are sets.

There is a use case for things like 1 < (1,3) making sense and denoting
a total order. When you have a hetergenous list, having a total order
makes it possible to sort the list which will make it easier to
weed out duplicates. So why don't you demand a use case for the
new behaviour to counter this use case?

IMO it would be better if it was possible to associate some kind
of order function with the container. Because the order most usefull
for comparing between two instances doesn't need to be the most usefull
order in finding an element from a container.

I could impose a total order on sets, so that I can use a bisection
algorithm on a container of them, but such an order is in general
less usefull than the superset ordering when you are manipulating
sets.

> Since we're talking about Py3K here, there is no
> "default" behavior. User-defined classes all inherit from builtin
> types, and will get the behavior of their comparison operators from
> those types. In particular, those that inherit from object will get
> objects behavior, which means they'll get equality as identity.

But if this makes any behaviour defined on objects consistent by
definition, because the only criteria you seem to have for consistency
is the inherited behaviour from object. If object would use a
random function to decide that would be consistent too, because it
would be the behaviour inherited by other classes. I don't find this
a usefull way to measure consistency.

>>> and won't provide
>>> examples to show why you want things to behave whatever way you want,
>>> I can't really say much else about it.
>> Did you see examples that show why Guido wants things to behave whatever
>> Guido's idea is a change from current behaviour. Each time I saw some
>> argue a change here, people seem to expect a use case from that person.
>> So why ask a use case of me and just accepy Guido's idea.
>
> For one thing, Guido has a long history of doing excellent Python
> design work. For another, this issue was thrashout out at length in
> comp.lang.python some years ago. What Guido proposed is inline with
> the conclusions of those discussions.

Then it should be easy to come up with the use cases and arguments pro
this idea presented then. If this idea of Guido was the result of his
briliance in language design, surely there should be arguments and
use cases to confirm that.

-- 
Antoon Pardon