Feature or enhancement

Proposal:

When IPython is embedded into a non-IPython interpreter, it evaluates code using frame locals (FrameLocalsProxy) in the same way aspdb does in Python stdlib.

This does not work with objects which require access to the closure scope:

• comprehensions in Python <3.13 (fixed for 3.13+ by inlining comprehensions introduced inPEP 709)
• generators

This bug affectedpdb module too (#65360) but it was fixed/worked around by:

• gh-83151: Make closure work on pdb #111094

For example, the following does not work:

importsyscall_frame=sys._getframe(0).f_backlocal_ns=call_frame.f_localsexec('x = 1; sum(x * i for i in range(5))',locals=local_ns)

Produces:

Traceback (mostrecentcalllast):File"<python-input-0>",line4,in<module>exec('x = 1; sum(x * i for i in range(5))',locals=local_ns)~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^File"<string>",line1,in<module>File"<string>",line1,in<genexpr>NameError:name'x'isnotdefined

I know thatFrameLocalsProxy has a few undocumented limitations, I am not sure if those are relevant here - I am linking the relevant issue just in case if that helps maintainers to refresh the context:

• Document FrameLocalsProxy behaviour quirks #125731

I am coming here from IPython, to explore if the solution belongs in IPython, or in CPython repo:

• a) couldexec handleFrameLocalsProxy specially in some way?
• b) as one option, could the same code as added forpdb ingh-83151: Make closure work on pdb #111094 (_exec_in_closure method) be included in the defaultexec implementation for whenFrameLocalsProxy is passed?
• c) if adding_exec_in_closure intoexec proper does not make sense, is it a good idea to explore moving_exec_in_closure out ofpdb and making it public?

The fix/workaround from#111094 is not perfect yet, though I think most of the problems could be resolved with a little bit more work. These issues were reported in:

• limitations of new multiline code and closure support in pdb #126958

If_exec_in_closure were exposed as public, there would be a bigger incentive for community to fix issues outlined in#126958, basically centralising the effort to make that work well.

On the other hand, if there are plans to inline generators in the future (I saw that PEP 709 leaved that as a possibility), maybe_exec_in_closure would no longer be necessary in the first place.

As an alternative to reusing_exec_in_closure, IPythoncould uselocals() call to populatelocals_ns which get passed down toexec vialocals argument when in embed mode; I am somewhat apprehensive to make this change as I worry it might break downstream code.

However, if you all advise that_exec_in_closure shall remain a privatepdb utility, this would likely tilt the the trade-off towards using thelocals() call, as otherwise IPython would need to maintain its own version of_exec_in_closure adding to maintenance cost on already over-stretched team.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

Not directly, but this is the third oldest unresolved issue in IPython dating back over 15 years:

• Global variables undefined in interactive use of embedded ipython shell ipython/ipython#62
• IPythonShellEmbed fails to recognize local variables ipython/ipython#136
• Variable not recognized in nested or filtered list comprehension under IPython.embed() ipython/ipython#12199

CC@gaogaotiantian if I may, as author of#111094 and assignee on#126958