Rich Comparisons Gotcha

[M.-A. Lemburg]

On 2008-12-10 16:40, Luis Zarrabeitia wrote:
> Quoting Rasmus Fogh <rhf22 at mole.bio.cam.ac.uk>:
>> Rhamphoryncus wrote:
>>> You grossly overvalue using the "in" operator on lists.
>> Maybe. But there is more to it than just 'in'. If you do:
>>>>> c = numpy.zeros((2,))
>>>>> ll = [1, c, 3.]
>> then the following all throw errors:
>> 3 in ll, 3 not in ll, ll.index(3), ll.count(3), ll.remove(3)
>> c in ll, c not in ll, ll.index(c), ll.count(c), ll.remove(c)
>>
>> Note how the presence of c in the list makes it behave wrong for 3 as
>> well.
> 
> I think I lost the first messages on this thread, but... Wouldn't be easier to
> just fix numpy? I see no need to have the == return anything but a boolean, at
> least on Numpy's case. The syntax 'a == b' is an equality test, not a detailed
> summary of why they may be different, and (a==b).all() makes no little sense to
> read unless you know beforehad that a and b are numpy arrays. When I'm comparing
> normal objects, I do not expect (nor should I) the == operator to return an
> attribute-by-attribute summary of what was equal and what wasn't.
> 
> Why is numpy's == overloaded in such a counter intuitive way? I realize that an
> elementwise comparison makes a lot of sense, but it could have been done instead
> with a.compare_with(b) (or even better, a.compare_with(b, epsilon=e)). No
> unexpected breakage, and you have the chance of specifying when you consider two
> elements to be equal - very useful. 

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 ;-)

> 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).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 10 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2008-12-02: Released mxODBC.Connect 1.0.0      http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/