Why keep identity-based equality comparison?

[Mike Meyer]

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-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.

Yes it does. It presumes that all operators of all types either always
make sense, or there are always situations where they don't

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

Yes it does. It presumes that all operators either always make sesne,
or there are always situations where they don't.

>> 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.

I suggest you look up the meaning of the word "analogy".

>> 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.

Of course there are types for which the given behaviors don't make
sense.  However, we're not talking about user-defined relations on
user-defined types with syntax that isn't supported by the
language. We're talking about the builtin relationships defined on the
builtin types.

> 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?

Yes, there is. And you are perfectly free to implement a type that
behaves that way if you want to. I don't need a use case to "counter"
this one; I just need to show that this use case can be reasonably
covered by the proposed mechanism.

> 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.

No, it wouldn't. Order relationships are a property of the type, not
the container. The order relationships are right where they belong -
attached to the type. That notwithstanding, it's often practical to be
able to override the order function for some specific method (and
would be even if the order function were associated with the container
instead of the type), so some of the methods that use order allow you
to provide a function to use for them. If you really want a container
type that has an order function associated with it, you can write
one. If you want it made part of the language, you'll have to provide
a use case.

> 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.

And you're free to implement a subclass of sets that does that. If you
want to argue that the builtin sets should do that, you can - but
that's unrelated to the question of how the comparison operators
behave for the rest of the bulitin types. At least, it doesn't matter
unless you try and force all the types and operators to be the same.

>> 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.

But you can use a random function to decide no matter *how* the
bulitin relationships behave. That's part of the powero of Python - it
doesn't impose arbitrary constraints on what you can do. You seem to
think we should either disallow comparison operators from throwing
exceptions, or force them to throw exceptions under some unstated
conditions. But not all types are the same; some may not *have*
conditions under which all relational operators need to throw an
exception. And not all comparisons are the same; some may not *have*
conditions under which they need to throw an exception.

>>>> 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.

It's no easier for me to find them than for you to find them. And I'm
not guido - if you want his thoughts, you'll have to ask him.

    <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.