<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 21, 2014 at 7:46 PM, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Sat, Feb 22, 2014 at 9:06 AM, Greg Ewing <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:<br>
> Nick Coghlan wrote:<br>
>><br>
>> On 21 February 2014 13:15, Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br>
>><br>
>>> Generator expressions require parentheses, unless they would be<br>
>>> strictly redundant. Ambiguities with except expressions could be<br>
>>> resolved in the same way, forcing nested except-in-except trees to be<br>
>>> correctly parenthesized<br>
>><br>
>><br>
>> I'd like to make the case that the PEP should adopt this as its<br>
>> default position.<br>
><br>
><br>
> I generally agree, but I'd like to point out that this<br>
> doesn't necessarily mean making the parenthesizing rules as<br>
> strict as they are for generator expressions.<br>
><br>
> The starting point for genexps is that the parens are part of<br>
> the syntax, the same way that square brackets are part of<br>
> the syntax of a list comprehension; we only allow them to<br>
> be omitted in very special circumstances.<br>
><br>
> On the other hand, I don't think there's any harm in allowing<br>
> an except expression to stand on its own when there is no<br>
> risk of ambiguity, e.g.<br>
><br>
> foo = things[i] except IndexError: None<br>
><br>
> should be allowed, just as we allow<br>
><br>
> x = a if b else c<br>
><br>
> and don't require<br>
><br>
> x = (a if b else c)<br>
<br>
</div>I'm inclined to agree with you. I fought against the mandated parens<br>
for a long time. Would be happy to un-mandate them, as long as there's<br>
no way for there to be ambiguity. Is CPython able to make an operator<br>
non-associative? That is, to allow these:<br>
<br>
value = expr except Exception: default<br>
value = (expr except Exception: default) except Exception: default<br>
value = expr except Exception: (default except Exception: default)<br>
<br>
but not this:<br>
<br>
value = expr except Exception: default except Exception: default<br>
<br>
? </blockquote><div><br></div><div>Yes, although how to do it depends on what else 'default' and 'expr' can be. The simple answer is to make 'expr' and 'default' be subsets of expressions that don't include the 'except' expression themselves. Just like how in 'A if C else B', 'A' and 'C' do not include the 'if' syntax, but 'B' does: you need parentheses in '(a if c1 else b) if c2 else d' and 'a if (c1 if c3 else c2) else b' but not in 'a if c1 else b if c2 else d'.</div>
<div><br></div><div>However, the question becomes what to do with 'lambda' and 'if-else'. Which of these should be valid (and mean what it means with the parentheses, which is how the PEP currently suggests it should be; ones without parenthesized alternatives are unambiguous, as far as I can tell.)</div>
<div><br></div><div>1. make_adder(x) except TypeError: lambda y: y + 0</div><div><br></div><div>2. lambda x: x + 0 except TypeError: 1</div><div>-> lambda x: (x + 0 except TypeError: 1)</div><div><br></div><div>3. A if f(A) except TypeError: C else B</div>
<div><br></div><div>4. f(A1) except TypeError: A2 if C else B</div><div>-> f(A1) except TypeError: (A2 if C else B)</div><div><br></div><div>5. f(A1) except TypeError if C else ValueError: f(A2)</div><div><br></div><div>
6. A if C else f(B) except TypeError: B</div><div>-> (A if C else f(B)) except TypeError: B</div><div><br></div><div>7. f(A) except E1(A) except E2(A): E2: E1 </div><div>-> f(A) except (E1(A) except E2(A): E2): E1</div>
<div><br></div><div>8. f(A) or f(B) except TypeError: f(C)</div><div>-> (f(A) or f(B)) except TypeError: f(C)</div><div><br></div><div>9. f(A) except TypeError: f(B) or f(C)</div><div>-> f(A) except TypeError: (f(B) or f(C))</div>
<div><br></div><div>10. A == f(A) except TypeError: B</div><div>-> (A == f(A)) except TypeError: B</div><div><br></div><div>11. f(A) except TypeError: A == B</div><div>-> f(A) except TypeError: (A == B)</div><div><br>
</div><div>12. A + B except TypeError: C</div><div>-> (A + B) except TypeError: C</div><div><br></div><div>13. f(A) except TypeError: A + B</div><div>-> f(A) except TypeError: (A + B)</div><div><br></div><div>#6 in particular and to some extent #4, #8 and #10 look wrong to me, so if they'd be allowed without parentheses perhaps the precedence of if-expr and except should be more nuanced. ('between lambda and ifexpr' is not really a sensible way to describe precedence anyway, since despite the insistence of the reference manual, the precedence of 'lambda' and 'ifexpr' is at best 'mixed': the grammar actually tries to match ifexpr first, but it works the way we all expect because 'lambda' is not an infix operator.)</div>
<div><br></div><div>It's easy to disallow most of these (allowing only their parenthesized versions), the question is where to draw the line :) Some of these require a bit more work in the grammar, duplicating some of the grammar nodes, but it shouldn't be too bad. However, disallowing any infix operators in the 'default' expression means it'll still be valid, just mean something different; #9, for example, would be parsed as '(f(A) except TypeError: f(B)) or f(C)' if the 'default' expression couldn't be an or-expression. Disallowing it in the 'expr' expression wouldn't have that effect without parentheses.</div>
<div><br></div><div>(FWIW, I have a working patch without tests that allows all of these, I'll upload it tonight so people can play with it. Oh, and FWIW, currently I'm +0 on the idea, -0 on the specific syntax.)</div>
</div>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank">thomas@python.org</a>><br><br>Hi! I'm an email virus! Think twice before sending your email to help me spread!
</div></div>