On 21/02/2014 23:36, Ethan Furman wrote:
On 02/21/2014 02:26 PM, Eric V. Smith wrote:
On 2/21/2014 5:06 PM, Greg Ewing wrote:
On 21 February 2014 13:15, Chris Angelico wrote:
Generator expressions require parentheses, unless they would be strictly redundant. Ambiguities with except expressions could be resolved in the same way, forcing nested except-in-except trees to be correctly parenthesized
There would be no ambiguity if only nested excepts are allowed. If one wants to catch multiple exceptions from one expression, /and do something different for each one/, use the statement form as it's going to be clearer. For example:
try: value = 1/x except ZeroDivisionError: try: value = 1/default['denominator'] except KeyError: value = NaN
is much cleaner as:
value = 1/x except ZeroDivisionError: 1/default['denominator'] except KeyError: NaN
However, this:
try: result = Parse(some_stuff) except MissingOperator: result = ... except InvalidOperand: result = ... except SomethingElse: result = ...
would not benefit from being condensed into a single expression
-- ~Ethan~ Funny, my feeling was exactly the reverse. :-) Probably because the latter seems to me to be a more natural thing to want to do (I find it easier to imagine use cases for it). And also because there is no way of getting exactly the same effect with a parenthesized except-expression: (expr except ValueError: ValueErrrorMessage") except NameError:NameErrorMessage # doesn't quite do what I want (here if expr raises a ValueError, evaluating ValueErrrorMessage which is mis-spelt will raise a NameError which will be misleadingly caught). But I guess the truth is that any except-expression which gets too long and complicated should be written some other way.