On Fri, Apr 8, 2011 at 10:52 AM, Mike Graham <mikegraham@gmail.com> wrote:
On Fri, Apr 8, 2011 at 1:11 PM, Guido van Rossum <guido@python.org> wrote:
With apologies for not reading the PEP or this thread in full, some comments:
- I really like the syntax "except <exc> [as <var>] [if <test>]:". This addresses a pretty common use case in my experience. I don't care for the alternate proposed syntax that started this thread. I'm not sure that the 'if' subclause makes sense without the 'as' subclause, since most likely you'd want to refer to the caught exception. I note that it is more powerful than putting "if not <test>: raise" in the body of the except-clause, because it will allow subsequent except clauses to match still. I also note that it is a much "cleaner" change than (again) reorganizing the exception hierarchy, since there is no backward compatibility to consider.
Of course, multiple cases can currently be handled by an if statement
except Foo as e: if e.bar == baz: ... elif e.bar == qux: ... else: raise
This code isn't so bad: it's not hard to understand, it's an existing pattern, it uses general, powerful constructs.
The problem (as I tried to say, but apparently not clearly enough) is that if there's a later more general except clause on the same block it won't work. E.g. except Foo as e: <code as above> except Exception: <log traceback> The 'raise' in your code above does not transfer control to the "except Exception:" clause. The current solution is either to have two nested try/except blocks, or duplicate the logging code; neither is great.
I think the main opposition is "People aren't currently doing this!"
People aren't currently doing what? I have seen many examples like that, and have myself encountered several times the problem I explained just now.
The problem is, introducing the "except...if" syntax doesn't actually make anyone do it either. I understand that adding syntax can be seen as a nudge, but I'm skeptical that it's a strong enough one to justify the cost.
What cost? Adding new optional syntax that doesn't introduce new keywords is actually pretty cheap -- certainly cheaper than restructuring the exception hierarchy. -- --Guido van Rossum (python.org/~guido)