![](https://secure.gravatar.com/avatar/f3ba3ecffd20251d73749afbfa636786.jpg?s=120&d=mm&r=g)
On 21 February 2014 22:42, Chris Angelico <rosuav@gmail.com> wrote:
It'd be a backward-incompatible change, but it's more likely to be what people expect. The general assumption of "with ... as ..." is that the thing should be used inside the block, and should be finished with when you exit the block, so having the name valid only inside the block does make sense.
That's a completely separate proposal. But suppose that were to happen, and to not require a closure. It would then make good sense to be able to capture an exception inside an expression - and it could be done without breaking anything.
So, if it is to be rejected, I'd say it's on the technical grounds that it would require a closure in CPython, and that a closure is incompatible with the current proposal. Does that sound right?
(It's also not a huge loss, since it's almost unused. But it's an incompatibility between statement and expression form.)
It's probably OK to leave it in the deferred section and just note the difficulty of implementing it in a backwards compatible way, since we're *not* going to be introducing a closure. Python 3 except clauses are already a bit weird anyway, since they do an implicit delete at the end, but only if the except clause is actually triggered:
e = "Hello" try: ... 1/0 ... except ZeroDivisionError as e: ... pass ... e Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'e' is not defined e = "Hello" try: ... pass ... except Exception as e: ... pass ... e 'Hello'
Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia