Stephen J. Turnbull wrote:
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.
Following up on my previous post, I think the general syntax would be something like: exception_expression :== nominal_value {except exception_tuple exception_value}* {except default_value} Hopefully this disambiguates the issue, at least from the parser point of view. Requiring an explicit tuple of exceptions (ie., requiring the parens around the tuple of exceptions) makes sense too, and I thought I had seen other discussions of requiring explicit tuples where currently parens could be implied. With the definition above, I think the combinations of exception expressions with if-else conditional expressions is probably also unambiguous (though not necessarily easily read). I haven't sat down to verify this mathematically yet though. Allowing parens around the except clauses might help to make it more readable? x = float(string) (except (ValueError,) float('nan')) (except (SomeOtherException,) someOtherValue) Okay, maybe not? (BTW: thanks for the cool new verb -- disambiguate -- though my friends and family may not be so happy when I start using it at every opportunity!) -- ========================== Jeffrey E. McAninch, PhD Physicist, X-2-IFD Los Alamos National Laboratory Phone: 505-667-0374 Email: mcaninch@lanl.gov ==========================