[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

AltStyle によって変換されたページ (->オリジナル) /