Rich Comparisons Gotcha
kyrie at uh.cu
Wed Dec 10 20:01:35 CET 2008
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() == 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.
More information about the Python-list