[Python-ideas] except expression

[Rob Cliffe]

On 19/02/2014 08:23, Bruce Leban wrote:
>
> On Tue, Feb 18, 2014 at 11:06 PM, Chris Angelico <rosuav at gmail.com 
> <mailto:rosuav at gmail.com>> wrote:
>
>     However, I'm removing two parts of the proposal: ... chaining of
>
>     excepts (use parens, "(expr except Exception1: default1) except
>     Exception2: default2").
>
>
> There are two problems with trying to leave this out.
>
> First, you say "use parens" but no use of parenthesis can have the 
> same effect. The alternative you give:
> (expr except E1: default1) except E2: default2
> is not the same as the chained form. This catches E2 in both the 
> evaluation of E1 *_and_* the evaluation of default1 while the chained 
> form catches both exceptions only in the evaluation of E1. And putting 
> parens anywhere else doesn't do it either.
>
> Second, isn't an except expression like any other expression which can 
> be used anywhere an expression can be? So that means that writing 
> something that looks like a chained expression without parenthesis 
> _*will*_ be a valid expression and will have to have some 
> interpretation (depending on whether except is left associative or 
> right associative.
+1.
I now see that the semantics of

expr1 except E1: (default1 except E2: default2)

and

(expr1 except E1: default1) except E2: default2

are not the same (in an earlier post I thought they were).

And neither of them are the same as:

Evaluate expr1 and see what exception it raises:
     If it raises E1, return default1
     If it raises E2, return default2.

(To spell it out, as much for my own benefit as anything else:
     The first catches E2 in the evaluation of default1.
     The second catches E2 in the evaluation of expr1 OR default1.
     The last catches E2 in the evaluation of expr1 only.
)
I suggest the form without brackets should (be legal and) mean the last 
of these, because
     (1) It feels to me like the natural meaning
     (2) It can't conveniently be expressed otherwise without 
introducing additional syntax.

Rob Cliffe

>
> Given that, I think it is better to define it as chained now rather 
> than leaving people to think it's chained and never being able to add 
> it in the future (since that will change the semantics of existing 
> code). This is analogous to handling a < b < c: it's a bug magnet in C 
> for inexperienced programmers but can't be changed without breaking 
> code. Starting from scratch in Python, it could be chained.
>
> --- Bruce
> Learn how hackers think: http://j.mp/gruyere-security
>
>
> _______________________________________________
> 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/6606 - Release Date: 02/19/14
>

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