On 28 February 2014 21:46, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman <v+pyt...@g.nevcal.com> > wrote: >> > Are there any other expressions that allow parens around a part of the >> > expression, without the stuff inside them becoming a completely >> > separate sub-expression? >> >> Sure. Function invocation. You can claim (and it is accurate) that the >> stuff inside is somewhat independent of the actual function called, but the >> syntax is function-name open-paren parameter-list close-paren, and the >> stuff in the parens would be a tuple if it were purely data, except not >> quite a tuple because some items are pairs (name and value), but it winds up >> being neither a tuple, nor a list, nor a dict, but instead a complex >> structure related to code execution :) > > Thanks, that's exactly the sort of example I was looking for :) For > some reason I mentally blanked and didn't think of that. My point is, > if you're going to look for parens around the bit after except, we > should look at styling and layout that follows how that's done.
Also generator expressions and most uses of yield or yield from as embedded expressions. Parentheses are our general "this next bit may not be following the normal syntax rules" utility, in addition to being used to override the normal precedence rules (square brackets and curly braces similarly denote regions where the parsing rules may differ from the top level ones). As far as the specific problem I'm attacking with this variant of the proposal goes, one of the recurring reactions from different people has been "but colons are used to introduce suites, not expressions". This impression is not, in fact, correct, as the colon is already used as a subexpression separator in four cases: * dict display key:value pairs * slice notation start:stop:step triples * function parameter : annotation separation * lambda expression arg list : return value separation PEP 463 just adds a fifth such case, as an exception spec:result separator. The preferred notation in the PEP most resembles the existing lambda use case, with "except" instead of "lambda", an exception handling spec instead of an argument list and an additional leading expression: (expr except Exception: default) Lots of people don't like the lambda notation though, so it isn't necessarily a particularly compelling parallel to use. By contrast, it's rare to hear any objections to the {key:value} dict display syntax. Hence the proposed tweak to the syntax to define an "exception handler expression" syntax that is analogous to a dict display rather than a lambda expression: expr except (Exception: default) However, I have realised that there *is* a major downside to that notation, which is that it lacks the connotations of lazy evaluation associated with lambda expressions, whereas the default result of an except expression won't be evaluated at all if the exception isn't thrown. So I think that on balance, I actually do prefer your current proposal. That said, I do think this is a variant worth discussing explicitly in the PEP, if only to remind people that there's definitely precedent for using a colon to separate two subexpressions inside a larger expression element - it's not *just* used to introduce suites, even though that is by far the most *common* use case. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com