On Fri, 30 Oct 2020 at 20:52, Fabio Zadrozny <fabi...@gmail.com> wrote: > On Fri, Oct 30, 2020 at 7:02 AM Nick Coghlan <ncogh...@gmail.com> wrote: > As a note, the current implementation does allow debuggers to mutate frame > locals -- as long as they understand that they need to call ` > PyFrame_LocalsToFast ` when doing such a change -- potentially using ctypes > (I'm just mentioning this because PEP 558 seems to imply this isn't possible).
If that's referring to the sentence that ends with ".. without even reliably enabling the desired functionality of allowing debuggers like pdb to mutate local variables.", the critical word there is "reliably". The existing API and implementation does allow you to change local variables from trace functions (especially if you use ctypes to access the C API rather than sticking solely to the Python level API), it just also messes up your application state sometimes. > i.e.: Debuggers already *must* call ` PyFrame_LocalsToFast ` if locals from a > frame which is not the current frame are being mutated, so, as far as I can > see a debugger is already broken if it isn't doing that -- some years ago I > even thought about exposing it in the frame API: > https://bugs.python.org/issue1654367, but in the end accessing it through the > C-API through ctypes does get the job done, debugger authors just need to be > aware of it -- PyPy also has a counterpart mentioned in that issue. It isn't primarily debuggers that are a concern for backwards compatibility, it's trace functions manipulating the state of the frame being traced. In the current implementation, that feature relies on those FastToLocals and LocalsToFast conversion calls to work. > I agree that having f_locals be a proxy that does everything transparently > would be better, but unfortunately I don't currently have the time available > to help there... in your opinion, just removing those calls as I proposed > (requiring that debuggers call `PyFrame_LocalsToFast`) would be acceptable? > If you think it is, I'll proceed on creating the PEP, otherwise I'll probably > just drop it until f_locals becomes a proxy (in which case I'd expect the > `PyFrame_FastToLocalsWithError` and `PyFrame_LocalsToFast` to be removed in > the same commit which converts f_locals to a proxy). Checking the PR branch, the write-through proxy meant I was able to get rid of the call to PyFrame_LocalsToFast, but I couldn't get rid of the implicit snapshot refresh due to C API compatibility concerns: https://github.com/python/cpython/pull/3640/files#diff-a3a5c73931235f7f344c072dc755d6508e13923db3f5d581c5e88652075871cb Assuming the PEP is eventually accepted, though, then it would be reasonable to subsequently deprecate that implicit refresh, and say that any trace function calling such APIs needs to make its own call to PyLocals_RefreshViews() first. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/JS7NEH4KS5CX3PHO6RVYPHJPRWBVWLRW/ Code of Conduct: http://python.org/psf/codeofconduct/
