[Python-Dev] Re: PEP 651: Robust Overflow Handling, version 2

Hi Guido, On 22/01/2021 5:20 am, Guido van Rossum wrote: On Wed, Jan 20, 2021 at 9:16 AM Mark Shannon > 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

[Python-Dev] Re: PEP 651: Robust Overflow Handling, version 2

On Wed, Jan 20, 2021 at 9:16 AM Mark Shannon 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 Minor question: what's the `where` argument to `Py_CheckStackDepth()` fo

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

> Do you have any specific examples? >From my previous message: gdb helpers, lldb helpers, TotalView debugger, py-spy and I know of at least 3 closed source tools. >I feel the responsibility for this belongs with the tool authors. > If they aren't using the C-API, or requesting an alternative int

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

Hi Pablo, On 20/01/2021 3:18 pm, Pablo Galindo Salgado wrote: >It depends on what you mean by "similar tools". Any 3rd party tool or debugger that is printing merged stacks. (There are many: gdb helpers, lldb helpers, TotalView debugger, py-spy, ...) For in-process tools, then the API will

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

>It depends on what you mean by "similar tools". Any 3rd party tool or debugger that is printing merged stacks. (There are many: gdb helpers, lldb helpers, TotalView debugger, py-spy, ...) > For in-process tools, then the API will continue to work. > For out-of-process debuggers, then the author'

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

Hi Pablo, On 19/01/2021 6:46 pm, Pablo Galindo Salgado wrote: Hi Mark, Thanks for gathering this proposal! Looks very interesting. I have some preliminary questions: how is this going to affect the "py-bt" command of the gdb helpers (https://github.com/python/cpython/blob/master/Tools/gdb/lib

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

> On 19 Jan 2021, at 17:15, Antoine Pitrou wrote: > > On Tue, 19 Jan 2021 15:54:39 + > Mark Shannon mailto:m...@hotpy.org>> wrote: >> On 19/01/2021 3:40 pm, Antoine Pitrou wrote: >>> On Tue, 19 Jan 2021 13:31:45 + >>> Mark Shannon wrote: Hi everyone, It's time for yet

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 1/19/2021 10:01 AM, Mark Shannon wrote: The following program will run safely to completion: I interpreted this to mean 'works now', on whatever system you tested this on. You question suggests that you meant "fails now but will work with a successful patch for the PEP". sys.setr

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

Hi Mark, Thanks for gathering this proposal! Looks very interesting. I have some preliminary questions: how is this going to affect the "py-bt" command of the gdb helpers (https://github.com/python/cpython/blob/master/Tools/gdb/libpython.py#L1876-L1897) and other similar tools that produce a uni

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, Jan 19, 2021 at 10:08 AM Mark Shannon wrote: > > > On 19/01/2021 5:48 pm, Guido van Rossum wrote: > > I'm not clear on how you plan to implement this in CPython. > > > > I can totally see that if a Python function calls another Python > > function, you can avoid the C stack frame and henc

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 5:48 pm, Guido van Rossum wrote: I'm not clear on how you plan to implement this in CPython. I can totally see that if a Python function calls another Python function, you can avoid the C stack frame and hence you can have as many Python call levels as you want. However, ther

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, 2021-01-19 at 16:22 +, Mark Shannon wrote: > > > On 19/01/2021 3:43 pm, Sebastian Berg wrote: > > On Tue, 2021-01-19 at 13:31 +, Mark Shannon wrote: > > > Hi everyone, > > > > > > It's time for yet another PEP :) > > > > > > Fortunately, this one is a small one that doesn't chan

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

I'm not clear on how you plan to implement this in CPython. I can totally see that if a Python function calls another Python function, you can avoid the C stack frame and hence you can have as many Python call levels as you want. However, there are many scenarios where a Python function calls a C

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, 19 Jan 2021 16:28:46 + Mark Shannon wrote: > On 19/01/2021 4:15 pm, Antoine Pitrou wrote: > > On Tue, 19 Jan 2021 15:54:39 + > > Mark Shannon wrote: > >> On 19/01/2021 3:40 pm, Antoine Pitrou wrote: > >>> On Tue, 19 Jan 2021 13:31:45 + > >>> Mark Shannon wrote: >

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 4:15 pm, Antoine Pitrou wrote: On Tue, 19 Jan 2021 15:54:39 + Mark Shannon wrote: On 19/01/2021 3:40 pm, Antoine Pitrou wrote: On Tue, 19 Jan 2021 13:31:45 + Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 3:43 pm, Sebastian Berg wrote: On Tue, 2021-01-19 at 13:31 +, Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. Abstract This PEP proposes that

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, 19 Jan 2021 15:54:39 + Mark Shannon wrote: > On 19/01/2021 3:40 pm, Antoine Pitrou wrote: > > On Tue, 19 Jan 2021 13:31:45 + > > Mark Shannon wrote: > >> Hi everyone, > >> > >> It's time for yet another PEP :) > >> > >> Fortunately, this one is a small one that doesn't change mu

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 3:40 pm, Antoine Pitrou wrote: On Tue, 19 Jan 2021 13:31:45 + Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. On the principle, no objection. In pra

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, 2021-01-19 at 13:31 +, Mark Shannon wrote: > Hi everyone, > > It's time for yet another PEP :) > > Fortunately, this one is a small one that doesn't change much. > It's aim is to make the VM more robust. > > Abstract > > > This PEP proposes that machine stack overflow is tr

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On Tue, 19 Jan 2021 13:31:45 + Mark Shannon wrote: > Hi everyone, > > It's time for yet another PEP :) > > Fortunately, this one is a small one that doesn't change much. > It's aim is to make the VM more robust. On the principle, no objection. In practice, can you show how an implementatio

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 2:38 pm, Terry Reedy wrote: On 1/19/2021 8:31 AM, Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. Abstract This PEP proposes that machine stack ov

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 1/19/2021 8:31 AM, Mark Shannon wrote: It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. Abstract This PEP proposes that machine stack overflow is treated differently from runaway recursion. M

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 1/19/2021 8:31 AM, Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. Abstract This PEP proposes that machine stack overflow is treated differently from runaway r