[Python-ideas] exception based conditional expression, similar to if-else conditional expression
Stephen J. Turnbull
stephen at xemacs.org
Thu Aug 20 04:31:20 CEST 2009
Jeff McAninch writes:
> _*Very Simple Example - type coercion:
> *_Current approach:
> try:
> x = float(string)
> except:
> x = float('nan')
>
> Proposed solution using exception-based conditional expression:
> x = float(string) except ValueError: float('nan')
-1
I really don't like the colon in the middle of the expression. It
just looks like broken syntax because everywhere else in Python colon
introduces a suite. I wonder if you really need it?
I generally don't like a general conditional expression. For reasons
presented below, I don't think it's as flexible as think it can be.
OTOH, I fund it much less readable than the existing statement-based
construction.
> _*Simple Example - type coercion in a list comprehension:
> *_Current approach:
> def safe_float(string):
> try:
> x = float(string)
> except ValueError:
> x = float('nan')
> return x
> ...
> xs = (safe(float(string)) for string in strings)
I don't have a problem with the above. But I can see that for
> In data processing, I often string together a sequence of iterable
> list comprehensions, corresponding to a sequence of operations on a
> given dataset "ys" to produce a processed dataset "x":
an exception-handling clause in comprehensions (and generator
expressions?) might be useful, to make the exceptions handled
explicit. For the cases I can imagine using myself, I would generally
prefer the approach of defining functions to handle the exceptions,
because they'd all be similar (eg, coercing exceptions to float("nan")
as above), though.
> try-except syntax. So the following examples would be allowed:
> x = expression0 except: default_expression
> x = expression0 except exception1: expression1 except exception2: expression2 except: default_expression
But it seems to me the ez-read interpretation of
x = expression0 except exception1: expression1 except: default_expression
is
x = expression0 except exception1: (expression1 except: default_expression)
Ie, your parser resolves the "dangling except" ambiguity in the
opposite way to the conventional resolution of the "dangling else"
ambiguity. And what if excepts are mixed with conditional
expressions?
x = exp0 except exc1: exp1 if exp2 else exp3 except: exp4
Does the bare except bind to exp0, the if expression, or exp3? I'm
sure you can define rules to disambiguate. However, I suspect that it
will be hard to get agreement that any given set of rules is the
appropriate way to resolve the ambiguity.
More information about the Python-ideas
mailing list