[Python-Dev] Another PEP 343 contextmanager glitch

[Guido van Rossum]

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/)