On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> 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/)
_______________________________________________
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
