On 10/7/2011 3:18 PM, Jim Jewett wrote:
On Thu, Oct 6, 2011 at 6:04 PM, Terry Reedytjreedy@udel.edu wrote:
On 10/6/2011 4:32 PM, Jim Jewett wrote:
On Wed, Oct 5, 2011 at 5:17 PM, Terry Reedytjreedy@udel.edu wrote:
On 10/4/2011 10:21 PM, Guido van Rossum wrote:
We also have str.index which raised an exception, but people dislike writing try/except blocks.
... try/except blocks are routinely used for flow control in Python ... even advocate using them over if/else (leap first)
str.index is a "little" method that it is tempting to use inline, even as part of a comprehension.
That is an argument *for* raising an exception on error.
Only for something that is truly an unexpected error. Bad or missing data should not prevent the program from processing what it can.
There is nothing specific to finding the index of a substring in a string in the above statement. If one has a collection of strings, some of which represent ints and some not, the failure of int(item) on some of them is not unexpected.
When I want an inline catch, it always meets the following criteria:
Please define 'inline catch' and show how to do it with str.find 'inline' without calling the function twice.
(a) The "exception" is actually expected, at least occasionally. (b) The exception is caused by (bad/missing/irrelevant...) input -- nothing is wrong with my computational environment. (c) I do NOT need extra user input; I already know what to do with it.
Typically, I just filter it out, though I may replace it with a placeholder and/or echo it to another output stream instead.
(d) The algorithm SHOULD continue to process the remaining (mostly good) data.
Again, nothing specific to why finding a substring index should be rather unique in having near-duplicate functions, one of which is clearly badly designed by using an inappropriate unix/c-ism.