Fabio Zadrozny <fabi...@gmail.com> added the comment:
@ncoghlan I took a quick look at the PEP... I'm a bit worried about: > On optimised frames, the Python level f_locals API will become a direct > read/write proxy for the frame's local and closure variable storage, and > hence no longer support storing additional data that doesn't correspond to a > local or closure variable on the underyling frame object. In particular, it's common for a debugger to evaluate expressions in a context that would change the locals to add new variables. i.e.: stopping at a breakpoint and doing 2 `exec` calls with frame.f_locals with: import some_module v = some_module.compute(xxx) So, it's expected that `some_module` and `v` would be in the locals at this point. Right now after each line of the evaluation, a `PyFrame_FastToLocals` must be called so things work as they should, but given that the PEP explicitly says that it should be deprecated, and this being a common feature for a debugger, what'd be the proper way to support that? p.s.: should I ask such questions regarding the PEP somewhere else instead of this issue or is this an appropriate place? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42197> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
