str.index() and str.find() versus only list.index()

[Steven D'Aprano]

On Tuesday 14 July 2015 14:07, Ian Kelly wrote:

> On Mon, Jul 13, 2015 at 9:23 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>> On Tue, 14 Jul 2015 01:12 pm, Ian Kelly wrote:
>>
>>> On Mon, Jul 13, 2015 at 10:56 AM, Roel Schroeven
>>> <roel at roelschroeven.net> wrote:
>>>> Hi,
>>>>
>>>> Quick question: why does str have both index() and find(), while list
>>>> only has index()? Is there a reason for that, or is it just an
>>>> historical accident?
>>>
>>> Historical accident, I think. If it were to be redone, I doubt that
>>> str.find would exist. The problem with it is that it returns -1 to
>>> indicate that the argument was not found, but -1 is a valid index into
>>> the string. This is a potential source of hard-to-find bugs.
>>
>> Correct. But rather than removing it, it would be better to take a leaf
>> out of re.match's book and return None as the sentinel. That would
>> eliminate the "using -1 as a valid index" bug.
> 
> I disagree on both counts.
> 
>>>> s = 'abc'
>>>> s[None:None]
> 'abc'


Well wadda ya know, I just learned something new. I was thinking more along 
these lines:

py> 'abc'[None]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string indices must be integers, not NoneType



> Better IMO to just have the one non-redundant method that raises an
> exception rather than returning anything that could possibly be
> interpreted as a string index.


Well, maybe, but if you got rid of str.find, the first thing people would do 
is recreate it:

def find(*args):
    try:
        return str.index(*args)
    except ValueError:
        return -1


Having a version of str.index that returns a sentinel is just too damn 
handy.



-- 
Steve