Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type

[Steve Holden]

Terry Reedy wrote:
> "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message 
> news:7xslww10ur.fsf at ruckus.brouhaha.com...
> 
>>Steve Holden <steve at holdenweb.com> writes:
>>
>>>Of course. But onc you (sensibly) decide to use an "if" then there
>>>really isn't much difference between -1, None, () and sys.maxint as
>>>a sentinel value, is there?
>>
>>Of course there is.  -1 is (under Python's perverse semantics) a valid
>>subscript.  sys.maxint is an artifact of Python's fixed-size int
>>datatype, which is fading away under int/long unification, so it's
>>something that soon won't exist and shouldn't be used.  None and ()
>>are invalid subscripts so would be reasonable return values, unlike -1
>>and sys.maxint.  Of those, None is preferable to () because of its
>>semantic connotations.
> 
> 
> I agree here that None is importantly different from -1 for the reason 
> stated.  The use of -1 is, I am sure, a holdover from statically typed 
> languages (C, in particular) that require all return values to be of the 
> same type, even if the 'return value' is actually meant to indicat that 
> there is no valid return value.

While I agree that it would have been more sensible to choose None in 
find()'s original design, there's really no reason to go breaking 
existing code just to fix it.

Guido has already agreed that find() can change (or even disappear) in 
Python 3.0, so please let's just leave things as they are for now.

A corrected find() that returns None on failure is a five-liner.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/