Rich Comparisons Gotcha

[Luis Zarrabeitia]

On Wednesday 10 December 2008 10:50:57 am M.-A. Lemburg wrote:
> On 2008-12-10 16:40, Luis Zarrabeitia wrote:
> > Quoting Rasmus Fogh <rhf22 at mole.bio.cam.ac.uk>:
> >> Rhamphoryncus wrote:
>
> Rich comparisons were added to Python at the request of the
> Numeric (now numpy) developers and they have been part of Python
> a Numeric for many many years.
>
> I don't think it's likely they'll change things back to the days
> of Python 1.5.2 ;-)

Please define "rich comparisons" for me. It seems that I do not understand the 
term - I was thinking it meant the ability to override the comparison 
operators, and specially, the ability to override them independently.

Even in statically typed languages, when you override the equality 
operator/function you can choose not to return a valid answer (raise an 
exception). And it would break all the cases mentioned above (element in 
list, etc). But that isn't the right thing to do. The language doesn't/can't 
prohibit you from breaking the equality test, but that shouldn't be 
considered a feature. (a==b).all() makes no sense. 

> > Even the transition itself could be done without breaking much code...
> > Make the == op return an object that wraps the array of bools (instead of
> > the array itself), give it the any() and all() methods, and make
> > __nonzero__/__bool__ equivalent to all().
>
> That would cause a lot of confusion on its own, since such an
> object wouldn't behave in the same way as say a regular Python
> list (bool([0]) == True).

I'm certain that something could be worked out. A quick paragraph that took me 
just a few minutes to type shouldn't be construed as a PEP that will solve 
all the problems :D.

-- 
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie