Le ven. 30 oct. 2020 à 11:02, Nick Coghlan
Ok, I've created https://bugs.python.org/issue42197 to track it.
Please also have a look at PEP 558 and its draft reference implementation at https://github.com/python/cpython/pull/3640
I don't think that the PEP 558 and bpo-42197 are incompatible. 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. By the way, I created https://bugs.python.org/issue40421 to prepare the C API to make the PyFrameObject structure opaque. Once it will be opaque, we will have more freedom on the API exposed to inspect frame locals. IMO it's a good idea to require function calls to inspect frame locals, and not let developers think that PyFrameObject.f_locals is always up-to-date and can always be modified. I dislike PyFrame_FastToLocalsWithError() and PyFrame_LocalsToFast() names. Maybe we should have an even more "explicit" API. Example (without error handling): --- // Implementation: Call PyFrame_FastToLocalsWithError() and returns PyFrameObject.f_locals locals = PyFrame_GetLocals(); // ... the debugger modifies some local variables in 'locals' dict ... // Implementation: Set PyFrameObject.f_locals and call PyFrame_LocalsToFast() PyFrame_SetLocals(locals); --- The good news is that PyFrame_GetLocals() and PyFrame_SetLocals() can easily be reimplemented in Python 3.9 for my compatibility header file: https://github.com/pythoncapi/pythoncapi_compat Such API avoids a complex proxy and simply reuses a regular dict object (exiting PyFrameObject.f_locals). Victor -- Night gathers, and now my watch begins. It shall not end until my death.