Rich Comparisons Gotcha

[M.-A. Lemburg]

On 2008-12-10 23:21, Luis Zarrabeitia wrote:
> On Wednesday 10 December 2008 02:44:45 pm you wrote:
>>> 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.
>> Perhaps not in your application, but it does make sense in other
>> numeric applications, e.g. ones that work on vectors or matrixes.
>>
>> I'd suggest you simply wrap the comparison in a function and then
>> have that apply the necessary conversion to a boolean.
> 
> I do numeric work... I'm finishing my MSc in applied math and I'm programing 
> mostly with python. And I'd rather have a.compare_with(b), or 
> a.elementwise_compare(b), or whatever name, rather than (a==b).all(). In 
> fact, I'd very much like to have an a.compare_with(b, epsilon=e).all() (to 
> account for rounding errors), and with python2.5, all(a.compare_with(b)). 
> 
> Yes, I could create an element_compare(a,b) function. But I still can't use 
> a==b and have a meaningful result. Ok, I can (and do) ignore that, it's just 
> one library, I'll keep track of the types before asking for equality (already 
> an ugly thing to do in python), but the a==b behaviour breaks the lists (a in 
> ll, ll.indexof(a)) even for elements not in numpy. ¿Should I also ignore 
> lists?

You should perhaps reconsider your use of lists. Lists with elements
of different types can be tricky at times, so perhaps you either need
a different data type which doesn't scan all elements or a separate
search function that knows about your type setup.

The fact that comparisons can raise exceptions is not new to Python,
so this problem can pop up in other areas as well, esp. when using
3rd party extensions.

Regarding the other issues like new methods you should really talk
to the numpy developers, since they are the ones who could fix this.

> The concept of equality between two arrays is very well defined, as it is also 
> very well defined the element-by-element comparison. There is a need to test 
> for both - then the way to test for equality should be the equality test.
> 
>>> 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.
>> As always: the Devil is in the details :-)
> 
> Of course... 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 11 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/