[Python-Dev] PEP 343 - next steps

[Guido van Rossum]

[Nick]
> As I just added to the Wiki, dropping the issue completely works for
> me. I'm also far from convinced I'd covered all the corner cases
> (besides, blocking KeyboardInterrupt for an arbitrary amount of time
> made me uncomfortable).

OK.

> You'd mostly convinced me that RAII was rare in Python, but two
> possible use cases remained - files, and "call method X of object Y at
> the end of the block" (e.g. "closing()" from the PEP).
> 
> Both of those would require any async guarantee to cover evaluation of
> EXPR in order to be included in the guarantee. If with statements make
> no guarantees about async exceptions, then there is no problem (as
> there is officially no difference between the two styles).

Any exception, async or otherwise, that happens before the 'try' of
the translation is reached, does *not* cause __exit__ to be called.

I just realized that the assignment to VAR (if present) also has to be
represented by one or more opcodes, so a special guarantee that
__enter__() called by the same opcode that sets up the try cannot work
anyway. Forget I said anything about that.

> If we ever do resurrect the idea, I also realised a far simpler
> solution would involve moving evaluation of EXPR and the call to
> __enter__ inside the try/finally block, and having an internal flag to
> indicate whether or not __exit__ should be called as the block is
> exited. Far less screwing around with ceval.c, and far easier to get
> right.

We considered this at some point during the PEP 340/343/346 discussion
(in fact I had it this way in an early version of one of the PEPs),
and in the end decided against it. I believe the argument was that any
failure *before* __enter__() returns can be handled by try/except
clauses inside __init__() or __enter__().

Changing to this style later would be a major backward incompatibility
because the guarantees made to __exit__() are different.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)