Add test showing issue with PyExc_StopIteration #4810
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This test shows that, depending on how a StopIteration object is built in a C extension, the final result of an awaitable is visible or not at the python layer. The exception is "raised" by calling PyExc_SetObject(PyExc_StopIteration, value). When "value" is an instance of PyExc_StopIteration that has already been constructed with a value (i.e., "PyObject_CallOneArg(PyExc_StopIteration, x)") then the exception is seen as expected, and the final value "x" is seen. However, when "value" is "x" itself, the python layer gets a None object instead. This difference in construction of exceptions in C extensions (normalised v/s non-normalised exceptions) works seamlesly in CPython, but doesn't in PyPy. Note however that while developing this test and making it as minimal as possible, I played with a simpler C extension that had a generator, and using "yield from" from the python layer. That *did* work in both cases. This suggests that the issue is specific to how coroutines are handled in PyPy.
|
In GitLab by @rtobar on Jul 20, 2023, 10:30 added 1 commit
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In GitLab by @rtobar on Jul 19, 2023, 05:59
This test shows that, depending on how a StopIteration object is built in a C
extension, the final result of an awaitable is visible or not at the python
layer.
The exception is "raised" by calling PyExc_SetObject(PyExc_StopIteration,
value). When "value" is an instance of PyExc_StopIteration that has already
been constructed with a value (i.e., "PyObject_CallOneArg(PyExc_StopIteration,
x)") then the exception is seen as expected, and the final value "x" is seen.
However, when "value" is "x" itself, the python layer gets a None object
instead. This difference in construction of exceptions in C extensions
(normalised v/s non-normalised exceptions) works seamlesly in CPython, but
doesn't in PyPy.
Note however that while developing this test and making it as minimal as
possible, I played with a simpler C extension that had a generator, and using
"yield from" from the python layer. That did work in both cases. This suggests
that the issue is specific to how coroutines are handled in PyPy.
--HG--
branch : stopiteration-issue