Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #93771 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: str.index() and str.find() versus only list.index() Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-13 21:12 -0600
    Re: str.index() and str.find() versus only list.index() Steven D'Aprano <steve@pearwood.info> - 2015-07-14 13:23 +1000
      Re: str.index() and str.find() versus only list.index() Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-13 22:07 -0600
        Re: str.index() and str.find() versus only list.index() Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-07-14 14:58 +1000
          Re: str.index() and str.find() versus only list.index() Chris Angelico <rosuav@gmail.com> - 2015-07-14 15:13 +1000

#93771 — Re: str.index() and str.find() versus only list.index()

On Mon, Jul 13, 2015 at 10:56 AM, Roel Schroeven <roel@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.

There was a long thread from 2005 on python-dev proposing to remove
str.find in Python 3, but evidently it didn't make the cut:
https://mail.python.org/pipermail/python-dev/2005-August/055704.html

[toc] | [next] | [standalone]

#93773

On Tue, 14 Jul 2015 01:12 pm, Ian Kelly wrote:

> On Mon, Jul 13, 2015 at 10:56 AM, Roel Schroeven <roel@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.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#93775

On Mon, Jul 13, 2015 at 9:23 PM, Steven D'Aprano <steve@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@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'

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.

[toc] | [prev] | [next] | [standalone]

#93778

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

> On Mon, Jul 13, 2015 at 9:23 PM, Steven D'Aprano <steve@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@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

[toc] | [prev] | [next] | [standalone]

#93779

On Tue, Jul 14, 2015 at 2:58 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tuesday 14 July 2015 14:07, Ian Kelly wrote:
>
>> On Mon, Jul 13, 2015 at 9:23 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> 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

Which proves that None is not a valid index, but it is a valid slice
boundary. Given that the return value will often be used for slicing
as well as indexing, it'd be good to have something that's not valid
for either. How about -1.0? It's equal to -1 in case someone uses
(str.find(...) == -1), it's less than zero in case they do
(str.find(...) < 0), and it's invalid in both slices and string
subscripts. There's no way that can break anything, right?

... oh wait. XKCD 1172. And anyone who's adding 1 to the position and
using that as a slice boundary, which will smoothly and without error
work with the beginning of the string if something isn't found (eg
s[s.find("-"):] will be everything after the first hyphen, or the
whole string if there isn't one).

>> 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.

Same as dictionaries have [] and .get(), although find doesn't allow
you to change the sentinel.

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web