This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Rotem Yaari, Yury.Selivanov, georg.brandl, gregory.p.smith, gvanrossum, larry, ncoghlan, oconnor663, serhiy.storchaka, vstinner, yselivanov
Date 2016-06-13.19:52:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465847570.94.0.78179897347.issue25782@psf.upfronthosting.co.za>
In-reply-to
Content
For both of the proposed patches, could we add a test case based on contextlib.ExitStack and a variant of Victor's #27122 reproducer script at http://bugs.python.org/file42999/hang_bug2.py that uses a deliberately broken __exit__ implementation that always re-raises the exception thrown into the underlying generator?

As discussed on that issue, I'm wondering if we need some additional defensive coding in ExitStack itself, or if resolving this underlying problem will be enough to also categorically prevent the hang in ExitStack.

As far as possible resolutions go, I tend to prefer lying about the shape of the exception state over changing the type of the raised exception - we already know the true exception state is a tree rather than a chain (see #18861 for some related discussions), and we should be able to ensure that all active exceptions remain somewhere in the chain, even if their order is a bit surprising.
History
Date User Action Args
2016-06-13 19:52:50ncoghlansetrecipients: + ncoghlan, gvanrossum, georg.brandl, gregory.p.smith, vstinner, larry, Yury.Selivanov, serhiy.storchaka, yselivanov, oconnor663, Rotem Yaari
2016-06-13 19:52:50ncoghlansetmessageid: <1465847570.94.0.78179897347.issue25782@psf.upfronthosting.co.za>
2016-06-13 19:52:50ncoghlanlinkissue25782 messages
2016-06-13 19:52:50ncoghlancreate