[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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
