Plea for __eql__

Remco Gerlich scarblac-spamtrap at pino.selwerd.nl
Sun May 21 20:21:50 EDT 2000


Robert Roy wrote in comp.lang.python:
> > 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.

This is enough. It's just that __cmp__ isn't easy to define.

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

Let's give an example. I'm writing a set of functions that have to do with
positions in a chess game. Given two Positions A and B, A != B is obvious to
implement. But to implement that in Python, I have to define __cmp__ - so
not only do I have to define when two positions are equal, I also have to
define when one is smaller than the other - but that is undefined! '<'
should raise an exception, even though '!=' is reasonable.

> It doesn't matter how complex an
> object a is, there is no good reason to raise an exception during the
> comparison. 

Sure there is - if there is no order defined, and the objects shouldn't be
compared as if there was an order (and __cmp__ does that).

The problem is that '==' and '!=' are related to an order function, even
though they make sense without an order.

Chess positions *could* have a useful order, but it wouldn't be a *complete*
order (ie, a < b when a has less pieces on the board - but not all different
positions can be compared that way, some positions have the same pieces on
different squares). Therefore, a 'rich comparisons' thing might solve this.

-- 
Remco Gerlich,  scarblac at pino.selwerd.nl
  Murphy's Rules, "Short game":
   In OSG's Starquest, each player rolls on a die at the beginning of the
   game --- there is a 1-in-6 chance he will be destroyed before he
   starts.



More information about the Python-list mailing list