bpo-29692: contextlib.contextmanager may incorrectly unchain RuntimeError #949
Conversation
|
@svelankar, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ncoghlan, @berkerpeksag and @Yhg1s to be potential reviewers. |
Lib/contextlib.py
Outdated
Lib/test/test_contextlib.py
Outdated
Lib/test/test_contextlib.py
Outdated
There was a problem hiding this comment.
Add some argument to the raised RuntimeError for checking that the correct RuntimeError is caught.
Lib/test/test_contextlib.py
Outdated
There was a problem hiding this comment.
Check that this is a RuntimeError raised by test_issue29692, not some other RuntimeError. Check it's __cause__ (it should be ZeroDivisionError, right?).
Lib/test/test_contextlib.py
Outdated
There was a problem hiding this comment.
What if raise StopIteration? I think this case should be tested too.
|
Please add an entry in |
soolabettu
force-pushed
the
bpo-29692
branch
2 times, most recently
from
ecf5deb to
9538527
Compare
|
Implemented all changes, please review, thanks. |
Lib/test/test_contextlib.py
Outdated
There was a problem hiding this comment.
Since from __future__ import generator_stop no longer used, the trick with exec() no longer needed.
Lib/test/test_contextlib.py
Outdated
Misc/NEWS
Outdated
There was a problem hiding this comment.
Add periods after sentence ends.
|
@serhiy-storchaka , thanks for the review. |
|
@ncoghlan could you please review the changes? Thanks |
ncoghlan
left a comment
ncoghlan
left a comment
There was a problem hiding this comment.
Latest version looks good to me.
|
Thanks for the fix, @svelankar! |
…ntimeError (pythonGH-949) 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 00c75e9)
…ntimeError (GH-949) (#1105) 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 00c75e9)
…ntimeError (pythonGH-949) 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 00c75e9)
…ntimeError (GH-949) (#1107) 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 00c75e9)
6 participants
@ncoghlan @serhiy-storchaka @JelleZijlstra @brettcannon
I had to close PR 891 and open a new PR due to an incorrect rebase on my part.
All review comments made in PR 891 have been implemented and a test case added, please review, thanks.