Plea for __eql__

[Robert Roy]

On Sun, 21 May 2000 13:54:42 -0700, Michael Ackerman
<ack at simplyweb.net> wrote:

>Hi. 
>Often there is only a partial order, or no natural order at all, on the
>instances of a class (eg sets, finite fields), but one still wants to
>ask whether two instances are equal (in a way appropriate for that
>type). To overload '==' for this purpose one now has to go through
>__cmp__, it seems to me, and so impose a sometimes artificial linear
>order.

While there is no natural order within each instance, there certainly
is some order between instances (based on the cardinality of the set
etc...). If the ordering between instances is irrelevant, then write
your __cmp__ method accordingly. 

> Wouldn't it be handy to have an __eql__ ? 

I think it would be redundant at best, a duplication of efforts at
worst.

Consider:
def __eql__(self, other):
	return not self.__cmp__(other)

(oops that is basically what '==' does)

would there ever be a reason to define it otherwise? If so please
explain thoroughly with examples.

>As things are now, it
>seems that there is no way to have '<' raise an exception without also
>having '!=' raise an exception in unwanted cases. Am I wrong?

And what would be an exceptional condition within a comparison? Either
a < b or it is not. End of story. It doesn't matter how complex an
object a is, there is no good reason to raise an  exception during the
comparison. That said there may be conditions that need to be
satisfied to do the comparison that will raise an exception but these
are not exceptions raised by the comparison per se.


>	More generally, would it be difficult to change Python so that
>programmers could define their own infix methods? Would it be desirable?
>(The modern functional languages allow this, without anarchy.)
>
>						-- Michael
>
>