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

[Terry Reedy]

"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message 
news:7xy86k3r7n.fsf at ruckus.brouhaha.com...

> Really it's x[-1]'s behavior that should go, not find/rfind.

I complete disagree, x[-1] as an abbreviation of x[len(x)-1] is extremely 
useful, especially when 'x' is an expression instead of a name.  But even 
if -1 were not a legal subscript, I would still consider it a design error 
for Python to mistype a non-numeric singleton indicator as an int.  Such 
mistyping is  only necessary in a language like C that requires all return 
values to be of the same type, even when the 'return value' is not really a 
return value but an error signal.  Python does not have that typing 
restriction and should not act as if it does by copying C.

> Will socket.connect_ex also go?

Not familiar with it.

>  How about dict.get?

A default value is not necessarily an error indicator.  One can regard a 
dict that is 'getted' as an infinite dict matching all keys with the 
default except for a finite subset of keys, as recorded in the dict.

If the default is to be regarded a 'Nothing to return' indicator, then that 
indicator *must not* be in the dict.  A recommended idiom is to then create 
a new, custom subset of object which *cannot* be a value in the dict. 
Return values can they safely be compared with that indicator by using the 
'is' operator.

In either case, .get is significantly different from .find.

Terry J. Reedy