Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type
steve at holdenweb.com
Sat Aug 27 17:14:46 CEST 2005
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
> 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.
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
More information about the Python-list