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