On Wed, 20 Jan 2021 at 19:22, Victor Stinner
Reply to an old thread.
On Sat, Oct 31, 2020 at 8:02 AM Nick Coghlan
wrote: Debuggers and profilers usually only care of specific frames or function calls (ex: 10% of function calls or even a single function call in a whole application). The problem is how to make them as efficient as possible for "no operation" calls, when they don't care about the current frame. Avoiding PyFrame_FastToLocalsWithError() to enter the debugger/profile and avoiding PyFrame_LocalsToFast() on exit sounds a simple and practical solution.
Aye, I agree. I just don't think we can remove those implicit calls without preparing a replacement API first.
Again, I don't think that it's incompatible. We can enforce calling PyFrame_FastToLocalsWithError() at enter and PyFrame_LocalsToFast() at exit for now, and enhance the API later.
PEP 558 makes `PyFrame_LocalsToFast()` raise an exception, so the two approaches definitely aren't compatible :)
To be clear: currently, PyFrame_FastToLocalsWithError() is called at enter and PyFrame_LocalsToFast() is called at exit. So asking debuggers/profilers to call them explicitly doesn't make the situation worse (nor better ;-)) for generators/coroutines, it would be exactly the same behavior. It's just an optimization.
The PEP 558 is being discussed for 5 years and still a draft. I don't think that it should hold bpo-42197 optimization.
No, what should hold up the bpo-42197 PR is the fact that it's an API compatibility break that shouldn't be done without a PEP. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia