[Python-ideas] Deprecate str.find

Georg Brandl g.brandl at gmx.net
Sat Jul 16 10:47:26 CEST 2011


Am 16.07.2011 05:43, schrieb Mike Graham:

>> Not to mention vague: it can often be quite hard to be sure the raised
>> exception came from just the operation you imagine it came from. With
>> str.find there's little scope for vagueness I agree (unless you aren't
>> really using a str, but a duck-type). But plenty of:
>>
>>  try:
>>    x = foofunc(y)
>>  except IndexError, e:
>>    ...
>>
>> is subject to uncaught IndexError arbitrarily deep in foofunc's call stack.
> 
> This is the strength and the flaw with exceptions period. It is a much
> broader question than the one we are facing here. If you do not like
> exceptions period or Python's use of relatively few exception types
> for many occasions, I really don't think we can start the discussion
> at the level of str.find.
> 
> If I did manage to have an IndexError propagate through to my
> SomeDuckType.index method when it shouldn't have the meaning I ascribe
> it, then this is a bug in my implementation of SomeDuckType. This bug
> would be very unfortunate because when a user tries to use my code
> right--catching the IndexError--they will completely squash the
> offending exception and the source of the bug will be unclear.
> Unfortunately, str.find is highly prone to such bugs as I've discussed
> since -1 is a valid index for the string.

By the way: str.index() raises ValueError, not IndexError, if the substring
isn't found.  That's one argument against "the index() API is foolproof,
while the find() API isn't".

Georg




More information about the Python-ideas mailing list