Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type
tjreedy at udel.edu
Tue Aug 30 10:14:42 CEST 2005
"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
In either case, .get is significantly different from .find.
Terry J. Reedy
More information about the Python-list