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. -- --Guido van Rossum (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-c...>
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-c...>
participants (2)
-
Guido van Rossum -
Mark Shannon