Rich Comparisons Gotcha

[Rhamphoryncus]

On Dec 10, 7:49 am, Rasmus Fogh <rh... at mole.bio.cam.ac.uk> wrote:
> 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.

All of these are O(n).  Use a set or dict.  What is your use case
anyway?


> > It's far more
> > common to use a dict or set for containment tests, due to O(1)
> > performance rather than O(n).  I doubt the numpy array supports
> > hashing, so an error for misuse is all you should expect.
>
> Indeed it doees not. So there is not much to be gained from modifying
> equality comparison with sets/dicts.
>
> > In the rare case that you want to test for identity in a list, you can
> > easily write your own function to do it upfront:
> > def idcontains(seq, obj):
> >     for i in seq:
> >         if i is obj:
> >             return True
> >     return False
>
> Again, you can code around any particular case (though wrappers look like
> a more robust solution). Still, why not get rid of this wart, if we can
> find a way?

The wart is a feature.  I agree that it's confusing, but the cost of
adding a special case to work around it is far in excess of the
original problem.

Now if you phrased it as a hypothetical discussion for the purpose of
learning about language design, that'd be another matter.