On Dec 10, 7:49 am, Rasmus Fogh <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
