[Python-ideas] Default return values to int and float

[Ron Adam]

On Fri, 2011-10-07 at 15:18 -0400, Jim Jewett wrote:
> On Thu, Oct 6, 2011 at 6:04 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> > On 10/6/2011 4:32 PM, Jim Jewett wrote:
> >> On Wed, Oct 5, 2011 at 5:17 PM, Terry Reedy<tjreedy at 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.
> 
> When I want an inline catch, it always meets the following criteria:
> 
> (a)  The "exception" is actually expected, at least occasionally. 

Sometime I feel exceptions are overly general.  Ok, so I got a
ValueError exception from some block of code...  But is it the one I
expected, or is it one from a routine in a library I imported and wasn't
caught or handled correctly.  (ie.. my routine called a function in
another module someone else wrote.)

One answer to that is to  put the try except around the fewest lines of
code possible so that it doesn't catch  exceptions that aren't related
to some specific condition.  That leads to possibly quite a few more
try-except blocks, and possibly more nested try-except blocks.  At some
point, it may start to seem like it's a better idea to avoid them rather
than use them.

What if you can catch an exception specifically from a particular
function or method, but let other unexpected "like" exceptions bubble
through...

   try:
      ...
      i = s.index('bar')
      ...
   except ValueError from s.index as exc:
      <handle s.index ValueError>

In this case, the only ValueError the except will catch is one
originating in s.index.

So instead of creating more exception types to handle ever increasing
circumstances, we increase the ability to detect them depending on the
context.

So then I can put a larger block of code inside a try-except and put as
many excepts on after the try block to detect various exceptions of the
same type, (or different types), raised from possibly different sub
parts within that block of code.  And if need be, let them bubble out,
or handle them.

Just a thought...

Cheers,
   Ron