On Tuesday 14 July 2015 14:07, Ian Kelly wrote:
> On Mon, Jul 13, 2015 at 9:23 PM, Steven D'Aprano <st...@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
>>> <r...@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
--
https://mail.python.org/mailman/listinfo/python-list
