Plea for __eql__

Robert Roy rjroy at
Sun May 21 18:39:04 EDT 2000

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

>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

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

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

More information about the Python-list mailing list