contextlib._GeneratorContextManager.__exit__ includes a special case to deal with
PEP 479 RuntimeErrors created when `StopIteration` is thrown into the context
manager body.
Previously this check was too permissive, and undid one level of chaining on *all*
RuntimeError instances, not just those that wrapped a StopIteration instance.
(cherry picked from commit 00c75e9a45)
It took me quite a bit to figure out what this was referring to,
since the given issue number is wrong, and the original commit
message I found through git blame lists a different, also wrong
issue number... see https://bugs.python.org/issue27122#msg279449
(cherry picked from commit af88e7eda4)
managed by a contextlib.ExitStack() and one of the exit stack
generators catches and raises it in a chain, do not re-raise the
original exception when exiting, let the new chained one through.
This avoids the PEP 479 bug described in issue25782.
- Alex J Burke noticed a debugging raise in the commit that
fixed the original bug reported in issue 20317
- this showed that multiple iterations through the affected
loop wasn't actually being tested
- added test cases to ensure docstrings are reasonable
- also updates various comments in contextlib for accuracy
- identifed #19404 as an issue making it difficult to provide
good help output on generator based context manager instances
- explain single use, reusable and reentrant in docs
- converted suppress to a reentrant class based impl
- converted redirect_stdout to a reusable impl
- moved both suppress and redirect_stdout behind a functional
facade
- added reentrancy tests for the updated suppress
- added reusability tests for the updated redirect_stdio
- slightly cleaned up an exception from contextmanager
