This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author fabioz
Recipients Mark.Shannon, fabioz, ncoghlan, python-dev, vstinner
Date 2021-06-27.10:57:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1624791454.17.0.674277597529.issue42197@roundup.psfhosted.org>
In-reply-to
Content
@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?
History
Date User Action Args
2021-06-27 10:57:34fabiozsetrecipients: + fabioz, ncoghlan, vstinner, Mark.Shannon, python-dev
2021-06-27 10:57:34fabiozsetmessageid: <1624791454.17.0.674277597529.issue42197@roundup.psfhosted.org>
2021-06-27 10:57:34fabiozlinkissue42197 messages
2021-06-27 10:57:33fabiozcreate