Speaking for myself ... On Fri, Mar 5, 2021 at 7:04 AM Mark Shannon <m...@hotpy.org> wrote:
> Hi, > > Thanks for taking the time to consider the PEP. > > Although the PEP was rejected, I still believe that the safety > guarantees in PEP 651 are worth adding to Python in the future. > > To do that (maybe for 3.11), I need to understand your concerns better. > > Would you clarify a few points for me? > > On 03/03/2021 7:19 pm, Python Steering Council wrote: > > Hi Mark, > > > > Thank you for submitting PEP 651. The Steering Council has spent the > past two weeks reviewing PEP 651. After careful consideration, we have > decided to reject the PEP. The following were the key points that led us to > this decision: > > > > * The benefits are not compelling enough. Deep recursion is not a common > tool in > > Python, and even with PEP 651 it would not be efficient enough to > make it a common > > tool. > > > > * The benefit of PEP 651 is negated as soon as a non-Python function is > involved in the > > recursion, making the likelihood of it being useful even smaller. It > also creates > > easy pitfalls for users who do end up relying on recursion. > > Could you give an example pitfall? > > > > > * We believe the PEP understates the disruption created by the technical > solution of > > multiple Python stack frames per C call. Although this may be > solvable, it will > > certainly cause substantial disruption to existing debuggers, > tracers, and state > > inspection tools as they need to adapt to this change (which may not > be trivial). > > This is presumably the key objection. > Is there a particular tool that you feel would be problematic? > I have only looked at gdb and py-spy. > There's also any debugger that has an extension module component, e.g. debugpy. > > > > > * As the way to approach this will be platform-specific (as some parts > of the proposal > > are not portable), this can cause generic Python code to behave > differently on > > different platforms, making this kind of code less portable and less > predictable. > > > There are two issues here. Portability and changes to behaviour. > > Regarding portability, I have to admit that PEP is rather vague. > That's my fault; I should have done more implementation first :( > FWIW, I have an implementation that should be portable. > > https://github.com/python/cpython/compare/master...markshannon:pep-overflow-implementation > > Regarding changes to behaviour, I don't see how "generic" Python code > would behave differently on different platforms, except for cases where > it already does. > > In some cases, the PEP would have improved the situation. > > For example: > sys.setrecursionlimit(5000) > def f(): > f() > > Currently, it raises a RecursionError on linux, but crashes the > interpreter on Windows. > With PEP 651 it would have raised a RecursionError on both platforms. > > Am I missing something here? > So your example shows a user already comfortable in raising their recursion limit to work around needing more stack space to reach completion. What is stopping the user from continuing to raise the limit until they still reach their memory limit even with PEP 651? If you're worried about runaway recursion you will very likely hit that with the default stack depth already, so I personally don't see how a decoupled stack counter from the C stack specifically makes it any easier/better to detect runaway recursion. And if I need more recursion than the default, you're going to bump the recursion depth anyway, which weakens the protection in either the C or decoupled counter scenarios. Sure, it's currently platform-specific, but plenty of people want to push that limit based on their machine anyway and don't need consistency on platforms they will never run on, i.e. I don't see a huge benefit to being able to say that an algorithm consistently won't go past 5000 calls on all platforms compared to what the C stack protection already gives us (not to say there's zero benefit, but it isn't massive or widespread either IMO). I personally just don't see many people saying, "I really want to limit my program to an exact call stack depth of 5000 on all platforms which is beyond the default, but anything under is fine and anything over -- regardless of what the system can actually handle -- is unacceptable". Tack on the amount of changes required to give a cross-platform stack count and limit check compared to the benefit being proposed, and to me that pushes what the PEP is proposing into net-negative payoff.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QLVLXHHGTR3Z4ILS5D5FZWMEHXST7HZO/ Code of Conduct: http://python.org/psf/codeofconduct/
