[Python-ideas] except expression

Nick Coghlan ncoghlan at gmail.com
Wed Feb 19 13:28:59 CET 2014


On 19 February 2014 18:39, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Feb 19, 2014 at 7:23 PM, Bruce Leban <bruce at leapyear.org> wrote:
>> 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.
>
> Not quite; it could be made a SyntaxError to abut two except
> expressions without parens. Failing that, the without-parens form
> would always mean nesting (or what Steven calls chaining), and a
> future development that puts a single try with multiple excepts would
> have to be done with commas.
>
> But there's still one big question: What use-case have you for the
> multi-catch form? (Maybe call it "continued"? "extended"??) I went
> through the standard library and found pretty much nothing that even
> tripped my checks, and those were sufficiently borderline that they
> could just be left as statements.

There's a different way of addressing that concern: applying the same
syntactic restriction as is used for generator expressions, and
*always* require the parentheses. If using the ":" delimited syntax,
then the requirement would be unconditional, if using some other
separator (like "return" or "->"), then the parentheses could be
optional when the expression is the sole argument to a function call.

If someone later makes the case for allowing multiple except clauses,
then that's OK, since the parentheses to disambiguate are already
guaranteed to be present, regardless of context.

Either way, based on your survey of the stdlib, I agree with MAL's
suggestion to also rule out embedded name binding. The example you
give in the PEP of losing the distinction between whether an iterator
yielded a new incremental value or terminated and returned a final
value is another sign that allowing name binding is a potential bug
magnet, because it conflates two different return channels into one.
That's a very different thing from substituting in a known *default*
value when the operation fails, and definitely not a practice we want
to encourage.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list