[Python-Dev] PEP 463: Exception-catching expressions

[Yury Selivanov]

On 2/21/2014, 7:42 PM, Ethan Furman wrote:
> On 02/21/2014 11:04 AM, Yury Selivanov wrote:
>> On 2/20/2014, 10:15 PM, Chris Angelico wrote:
>>>
>>> * list.pop() - no way to return a default
>>
>> We can fix that in 3.5.
>
> How many are you going to "fix"?  How are you going to "fix" the 
> routines you don't control?

This new syntax won't magically fix all the code either.
But it may let people write code like this:

   # I'm sorry, I really can't read this.
   logging.info("Message shown to user: %s",((cache[k]
       except LookupError:
           (backend.read(k) except OSError: 'Resource not available')
       )
       if check_permission(k) else 'Access denied'
   ) except BaseException: "This is like a bare except clause")

or this:

   # We happily mask exceptions from getgrnam
   g = grp.getgrnam(tarinfo.gname)[2] except KeyError: tarinfo.gid

And this particular case or list.pop method, let's be honest,
can be fixed ;)

>
>>> * seq[index] - no way to handle a bounds error
>>
>> We can add 'list.get(index, default)' method, similar to
>> 'Mapping.get'. It's far more easier than introducing new
>> syntax.
>
> When I have to keep writing the same code over and over and aver 
> again, I find a better way to do the job.  In this case, an exception 
> expression does quite nicely.

I can't believe you find

    list[42] except IndexError: 'spam'

to be better than

    list.get(42, 'spam')

If IndexError is such a big deal, I think we can add this function
to list and collections.abc.Sequence. Authors of libraries
will follow.

>
>> I also searched how many 'except IndexError' are in
>> the standard library code.  Around 60.  That's a rather
>> low number, that can justify adding 'list.get' but not
>> advocate a new syntax.
>
> And roughly 200 of KeyError, another couple hundred of ValueError...
Many KeyErrors can be fixed with a proper use of '.get()', or 'in'
operator.

Many AttributeErrors can be fixed with use of getattr() or
hasattr(), or by designing a better API.

Many ValueErrors... wait, there are no ValueError examples
in the PEP, so I won't comment.

>
> This is not just about better handling of [missing] default values, 
> but of better exception handling.  This PEP adds the ability to use a 
> scalpel instead of a sledge hammer.

I'd say it's another sledge-hammer, but a tad smaller and a cuter
one (to some people).  But it's still exception handling, still
more code than a function call.


Yury