Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!multikabel.net!newsfeed20.multikabel.net!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Wed, 21 Nov 2012 20:58:46 +0000
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Inconsistent behaviour os str.find/str.index when providing optional parameters
References: <9ecd357d-aaaa-4f4d-a987-a478e92b2052@googlegroups.com> <tL7rs.628211$Ol2.3970@fx25.am4> <50ad2a95$0$6907$e4fe514c@news2.news.xs4all.nl>
In-Reply-To: <50ad2a95$0$6907$e4fe514c@news2.news.xs4all.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: python-list@python.org
Newsgroups: comp.lang.python
Message-ID: <mailman.175.1353531533.29569.python-list@python.org>
Lines: 99
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:33770

On 2012-11-21 19:25, Hans Mulder wrote:
> On 21/11/12 17:59:05, Alister wrote:
>> On Wed, 21 Nov 2012 04:43:57 -0800, Giacomo Alzetta wrote:
>>
>>> I just came across this:
>>>
>>>>>> 'spam'.find('', 5)
>>> -1
>>>
>>>
>>> Now, reading find's documentation:
>>>
>>>>>> print(str.find.__doc__)
>>> S.find(sub [,start [,end]]) -> int
>>>
>>> Return the lowest index in S where substring sub is found,
>>> such that sub is contained within S[start:end].  Optional arguments
>>> start and end are interpreted as in slice notation.
>>>
>>> Return -1 on failure.
>>>
>>> Now, the empty string is a substring of every string so how can find
>>> fail?
>>> find, from the doc, should be generally be equivalent to
>>> S[start:end].find(substring) + start, except if the substring is not
>>> found but since the empty string is a substring of the empty string it
>>> should never fail.
>>>
>>> Looking at the source code for find(in stringlib/find.h):
>>>
>>> Py_LOCAL_INLINE(Py_ssize_t)
>>> stringlib_find(const STRINGLIB_CHAR* str, Py_ssize_t str_len,
>>>                const STRINGLIB_CHAR* sub, Py_ssize_t sub_len,
>>>                Py_ssize_t offset)
>>> {
>>>     Py_ssize_t pos;
>>>
>>>     if (str_len < 0)
>>>         return -1;
>>>
>>> I believe it should be:
>>>
>>>     if (str_len < 0)
>>>         return (sub_len == 0 ? 0 : -1);
>>>
>>> Is there any reason of having this unexpected behaviour or was this
>>> simply overlooked?
>>
>> why would you be searching for an empty string?
>> what result would you expect to get from such a search?
>
>
> In general, if
>
>      needle in haystack[ start: ]
>
> return True, then you' expect
>
>      haystack.find(needle, start)
>
> to return the smallest i >= start such that
>
>      haystack[i:i+len(needle)] == needle
>
> also returns True.
>
>>>> "" in "spam"[5:]
> True
>>>> "spam"[5:5+len("")] == ""
> True
>>>>
>
> So, you'd expect that spam.find("", 5) would return 5.
>
> The only other consistent position would be that "spam"[5:]
> should raise an IndexError, because 5 is an invalid index.
>
> For that matter, I wouldn;t mind if "spam".find(s, 5) were
> to raise an IndexError.  But if slicing at position 5
> proudces an empry string, then .find should be able to
> find that empty string.
>
You'd expect that given:

     found = string.find(something, start, end)

if 'something' present then the following are true:

     0 <= found <= len(string)

     start <= found <= end

(I'm assuming here that 'start' and 'end' have already been adjusted
for counting from the end, ie originally they might have been negative
values.)

The only time that you can have found == len(string) and found == end
is when something == "" and start == len(string).