[Python-ideas] except expression

[Rob Cliffe]

On 18/02/2014 17:01, Alexander Belopolsky wrote:
>
> On Tue, Feb 18, 2014 at 11:25 AM, Paul Moore <p.f.moore at gmail.com 
> <mailto:p.f.moore at gmail.com>> wrote:
>
>     On 18 February 2014 15:51, Chris Angelico <rosuav at gmail.com
>     <mailto:rosuav at gmail.com>> wrote:
>     > On Wed, Feb 19, 2014 at 2:41 AM, Alexander Belopolsky
>     > <alexander.belopolsky at gmail.com
>     <mailto:alexander.belopolsky at gmail.com>> wrote:
>     >> I would not mind
>     >>
>     >>  x = 1/f(y) except 0
>     >>
>     >> not catching a TypeError that may come from f(y) in most cases.
>     >
>     > But should it catch a KeyError from inside f(y), based on the
>     > translation of d.get()?
>
>     Explicit is better than implicit - I think this discussion has done
>     its job and established that trying to assume a subset of exceptions
>     to catch isn't going to work. We either allow a bare except to mean
>     "catch all exceptions" (which exactly the same risks and provisos as a
>     bare except *statement*) or we make the exception to catch mandatory.
>
>
> I disagree.  It is best to leave explicit selection of exceptions to 
> catch outside of the expressions.  This is job for things like decimal 
> or numpy fp contexts.
>
> Always requiring a long camel-case name inside an expression will kill 
> most of the advantages.
>
> For example, it would be nice to be able to write something like
>
> x = d1[key] except d2[key] except 0
>
> but sprinkle this with repeated KeyError and what is important (d1 and 
> d2) will be lost in the scaffolding.
Hm.  Currently you can write

     x = d1.get(key, d2.get(key, 0))

which is admirably concise, and perhaps you like it.  Personally I don't 
find it particularly readable (and it is one of the API complications 
this proposal aims to make unnecessary).

If we move on from that, this proposal means that, even with sprinkling 
keywords you can replace:

try:
     x = d1[key]
except KeyError:
     try:
         x = d2[key]
     except KeyError:
         x = 0

with:

x = d1[key] except KeyError: (d2[key] except KeyError: 0)

Again this is subjective, but I find that a significant gain.  7 lines 
replaced by 1 not terribly long line.  Not many keystrokes saved, true.  
But no indents to type, and no visual jumping around the indents when 
reading it.  The new version is dense, yes, but I find it readable 
(Westerners find it natural to read left-to-right), explicit, and with 
every bit of it except the colons meaningful. Perhaps to be fair the 
short variable names "d1" and "d2" are a bit swamped by the longer 
exception name "KeyError".

To digress somewhat:

I typed in the parentheses to convey my intention without analysing 
whether they were necessary.  I don't think they are because, as far as 
I can see, the alternative reading

x = (d1[key] except KeyError: d2[key]) except KeyError: 0

would have exactly the same semantics, and still would do if "d1" and 
"d2" were replaced by more complicated expressions which themselves 
might raise a KeyError (which I find kind of reassuring, it means we 
don't have to decide a precedence of one "except" over another).  (Oops, 
now I seem to be almost arguing for the "d1.get(..." form which would 
propagate errors evaluating "d1" or "d2".)  But if I am missing 
something, I'd be interested.

Rob Cliffe

>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.2247 / Virus Database: 3705/6602 - Release Date: 02/17/14
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140218/6029f176/attachment.html>