Terry J. Reedy added the comment:
Lists, tuples, ranges, dicts, and other builtin collection objects already work
with 'in'.
>>> 1 in [1,2,3]
True
>>> 4 in range(9)
True
For historical reasons, stings have both 'find' and 'index'. The only
difference is returning -1 (a C-ism) versus raising ValueError on failure.
They are otherwise redundant.
Lists, tuples, and ranges, and other builtin sequence objects already have
'index'. There is no need to repeat the redundancy of 'find'.
>>> [1,2,3].index(2)
1
>>> [1,2,3].index(4)
Traceback (most recent call last):
File "<pyshell#7>", line 1, in <module>
[1,2,3].index(4)
ValueError: 4 is not in list
>>> range(9).index(4)
4
Strings are a special case of collection in that they 'contain' substrings
rather than items of a different class. For this reason, 'in' and index/find
are special-cased also work with contiguous substrings of length greater than 1.
>>> 'ac' in 'abc'
False
>>> 'ab' in 'abc'
True
Extending this idea to 'subsequence in sequence' or sequence.index(subsequence)
has been rejected.
Note: __cmp__ does not exist in 3.x. Collection 'in' and sequence 'index'
check object identity before equality to guarantee that an object in a
collection (in the common sense of the term) is actually found even if it has a
screwy definition of __eq__.
>>> nan = float('nan')
>>> nan == nan
False
>>> nan in [nan]
True
>>> float('nan') in [float('nan')]
False
>>> [nan].index(nan)
0
----------
nosy: +terry.reedy
resolution: -> rejected
stage: -> resolved
status: open -> closed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29511>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
