Rich Comparisons Gotcha

[James Stroud]

Rasmus Fogh wrote:
> Dear All,
> 
> For the first time I have come across a Python feature that seems
> completely wrong. After the introduction of rich comparisons, equality
> comparison does not have to return a truth value, and may indeed return
> nothing at all and throw an error instead. As a result, code like
>   if foo == bar:
> or
>   foo in alist
> cannot be relied on to work.
> 
> This is clearly no accident. According to the documentation all comparison
> operators are allowed to return non-booleans, or to throw errors. There is
> explicitly no guarantee that x == x is True.

I'm not a computer scientist, so my language and perspective on the 
topic may be a bit naive, but I'll try to demonstrate my caveman 
understanding example.

First, here is why the ability to throw an error is a feature:

class Apple(object):
   def __init__(self, appleness):
     self.appleness = appleness
   def __cmp__(self, other):
     assert isinstance(other, Apple), 'must compare apples to apples'
     return cmp(self.appleness, other.appleness)

class Orange(object): pass

Apple(42) == Orange()


Second, consider that any value in python also evaluates to a truth 
value in boolean context.

Third, every function returns something. A function's returning nothing 
is not a possibility in the python language. None is something but 
evaluates to False in boolean context.

> But surely you can define an equal/unequal classification for all
> types of object, if you want to?

This reminds me of complex numbers: would 4 + 4i be equal to sqrt(32)? 
Even in the realm of pure mathematics, the generality of objects (i.e. 
numbers) can not be assumed.


James


-- 
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com