[Python-Dev] Another PEP 343 contextmanager glitch (original) (raw)

Guido van Rossum guido at python.org
Sat Mar 25 00:50:33 CET 2006

On 3/24/06, Phillip J. Eby <pje at telecommunity.com> wrote:

At 03:27 PM 3/24/2006 -0800, Guido van Rossum wrote: >I guess I like the ambiguity -- to the outer exit, it shouldn't >make any difference whether the exception was re-raised by the inner >exit or by the finally clause containing it. After all, if there >wasn't an outer exit, there wouldn't be any difference to the >user either, whether the re-raise came from exit or from finally. > >If you still disagree, can you produce a test case that's currently broken?

I discovered the issue when I updated to the latest implementation and it broke the tests for a context manager I had written. This context manager is basically a transaction manager that accumulates context managers for resources used in the transaction, then calls all their exit() methods from its exit. It has to be able to distinguish between an exit() that failed (which means a critical failure of the overall transaction!) and an exit that's merely allowing the original exception to propagate (which means that the other handlers should still be invoked, and that everything's working normally).

It seems you're proposing something that is not equivalent to

with A: with B: ...

since in that case a failure of the inner exit (whether a re-raise or a real failure) would still invoke the outer exit. Is that a good idea?

I'm not against recommending in the PEP that exit shouldn't re-raise but instead should return False to signal a re-raise, and fixing any existing code that re-raises in exit. But I'm still questioning your use case; why is it important not to call the outer exit methods in your case?

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

More information about the Python-Dev mailing list