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

[David Townshend]

Many of these issues might be solved by providing a one line alternative to
the rather unwieldy try statement:

try:
    return function()
except ValueError:
    return default

I can't settle on a good syntax though. Two suggestions

return function() except(ValueError) default

return default if except(ValueError) else function()

The second is more readable, but seems a bit backwards, like it's handling
the exception before it occurs.

Is this idea worth pursuing if we can find the right syntax?
On Oct 8, 2011 5:52 AM, "Ron Adam" <ron3200 at gmail.com> wrote:

> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111008/4ac13136/attachment.html>