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 <[EMAIL PROTECTED]>: > >> 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 -- http://mail.python.org/mailman/listinfo/python-list