Inconsistent behaviour os str.find/str.index when providing optional parameters

[Joshua Landau]

If you reply through Google Groups, please be careful not to do it the
traditional way as us poor saps get hundreds of lines of ">" added in.

I believe (but this is mere recollection) that a good way to use the site
is by selecting the text you want to quote before replying (even if it is
the whole post). I'm not too sure, though.

On 22 November 2012 18:22, Giacomo Alzetta <giacomo.alzetta at gmail.com>wrote:

> <SNIP>
>
> My point was not to change the behaviour but only to point out this
> possible inconsistency between what str.find/str.index do and what they
> claim to do in the documentation.
>
> Anyway I'm not so sure that changing the behaviour would break many
> programs... I mean, the change would only impact code that was looking for
> an empty string over the string's bounds. I don't see often using the lo
> and hi parameters for find/index, and I think I never saw someone using
> them when they get out of bounds. If you add looking for the empty string I
> think that the number of programs breaking will be minimum. And even if
> they break, it would be really easy to fix them.
>
> Anyway, I understand what you mean and maybe it's better to keep this (at
> least to me) odd behaviour for backwards compatibility.
>
> <SNIP>
>
> Yeah, I understand what you say, but the logic you pointed out is never
> cited anywhere, while slices are cited in the docstring.
>
> <SNIP>
>

>
Definitely. The sentence "Optional
> arguments start and end are interpreted as in slice notation." should be
> changed to something like:
> "Optional arguments start and end are interpreted as in slice notation,
> unless start is (strictly?) greater than the length of S or end is smaller
> than start, in which cases the search always fails."
>
> In this way the 'spam'.find('', 4) *is* documented because start=len(S) ->
> start and end are treated like in slice notation and 4 makes sense, while
> 'spam'.find('', 5) -> -1 because 5 > len('spam') and thus the search fails
> and also 'spam'.find('', 3, 2) -> -1 makes sense because 2 < 3(this edge
> case makes more sense, even though 'spam'[3:2] is still the empty
> string...).


+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121122/2861c579/attachment.html>