PEP 651: Robust Overflow Handling, version 2

Hi,
I've updated the PEP in light of my experiments and feedback. The new API is simpler and a bit more backwards compatible.
https://www.python.org/dev/peps/pep-0651/
Cheers, Mark.

On Wed, Jan 20, 2021 at 9:16 AM Mark Shannon mark@hotpy.org wrote:
I've updated the PEP in light of my experiments and feedback. The new API is simpler and a bit more backwards compatible.
Minor question: what's the `where` argument to `Py_CheckStackDepth()` for?
The implementation section doesn't mention how you intend to avoid the C stack for Python-to-Python calls. I have some idea, but it would be nice if you explained this a bit more. (I'm guessing you are planning to move some state from local variables into the frame object, store a "return location" (really frame object + bytecode program counter) somewhere, and then jump to the top of `_PyEval_EvalFrameDefault()`, or at least somewhere near the top. Of course this requires adjusting the various `CALL_*` opcodes to check whether the target is a Python function or not. On `RETURN_VALUE` you reverse the process, but only if the call came from the previous mechanism. Do I get a lollipop? :-)
I'm guessing you needn't do anything for generators -- IIRC recursion through `next()` is not possible, since an active generator cannot be entered recursively.

Hi Guido,
On 22/01/2021 5:20 am, Guido van Rossum wrote:
On Wed, Jan 20, 2021 at 9:16 AM Mark Shannon <mark@hotpy.org mailto:mark@hotpy.org> wrote:
I've updated the PEP in light of my experiments and feedback. The new API is simpler and a bit more backwards compatible. https://www.python.org/dev/peps/pep-0651 <https://www.python.org/dev/peps/pep-0651/>
Minor question: what's the `where` argument to `Py_CheckStackDepth()` for?
The same as for Py_EnterRecursiveCall(where); it gets incorporated into the exception message.
The implementation section doesn't mention how you intend to avoid the C stack for Python-to-Python calls. I have some idea, but it would be nice if you explained this a bit more. (I'm guessing you are planning to move some state from local variables into the frame object, store a "return location" (really frame object + bytecode program counter) somewhere, and then jump to the top of `_PyEval_EvalFrameDefault()`, or at least somewhere near the top. Of course this requires adjusting the various `CALL_*` opcodes to check whether the target is a Python function or not. On `RETURN_VALUE` you reverse the process, but only if the call came from the previous mechanism. Do I get a lollipop? :-)
Yes you do. 🍭
I'll expand the PEP a bit to include that information.
I'm guessing you needn't do anything for generators -- IIRC recursion through `next()` is not possible, since an active generator cannot be entered recursively.
Yes. It might be nice to handle generators as well, but it is not necessary.
Cheers, Mark.
-- --Guido van Rossum (python.org/~guido http://python.org/~guido) /Pronouns: he/him //(why is my pronoun here?)/ http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/
participants (2)
-
Guido van Rossum
-
Mark Shannon