Jamed Stroud Wrote:
> 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()
True, but that does not hold for __eq__, only for __cmp__, and
for__gt__, __le__, etc.
Consider:
Class Apple(object):
def __init__(self, appleness):
self.appleness = appleness
def __gt__(self, other):
assert isinstance(other, Apple), 'must compare apples to apples'
return (self.appleness > other.appleness)
def __eq__(self, other):
if isinstance(other, Apple):
return (self.appleness == other.appleness)
else:
return False
> 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.
Indeed. The requirement would be not that return_value was a boolean, but
that bool(return_value) was defined and gave the correct result. I
understand that in some old Numeric/numpy version the numpy array __eq__
function returned a non-empty array, so that
bool(numarray1 == numarray2)
was true for any pair of arguments, which is one way of breaking '=='.
In current numpy, even
bool(numarray1 == 1)
throws an error, which is another way of breaking '=='.
>> 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.
It sounds like that problem is simpler in computing. sqrt(32) evaluates to
5.6568542494923806 on my computer. A complex number c with non-zero
imaginary part would be unequal to sqrt(32) even if it so happened that
c*c==32.
Yours,
Rasmus
---------------------------------------------------------------------------
Dr. Rasmus H. Fogh Email: [EMAIL PROTECTED]
Dept. of Biochemistry, University of Cambridge,
80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
--
http://mail.python.org/mailman/listinfo/python-list
