[issue9274] code.InteractiveInterpreter fails to change locals when invoked in a function

Eric Promislow report at bugs.python.org
Fri Jul 16 20:57:00 CEST 2010

Eric Promislow <ericp at activestate.com> added the comment:

I've modified the bug status so anyone can read it.  You
don't need an account to read ActiveState bugs, only to
add or comment on one.

Please note that I closed bug http://bugs.activestate.com/show_bug.cgi?id=87405, as we're now writing
to frame->f_localsplus[] to make sure changes to locals
stick.  I logged a different bug on Komodo's dependence
on this bug at


Here's how we run into this bug:

In Komodo, while you're debugging, you can push an
interactive shell, that uses the current state of the
program.  We build each block of code the user
types in a variable called source, and try executing
it like so: 

code.InteractiveInterpreter(locals()).runsource(source, "<console>")

In other words, we're letting the Python core do all the
heavy lifting identifying multi-line stmts, indented blocks,

We've had problems with modifying local variables in the
Python debugger for years (almost a decade now).  I got
a C extension working using frame->f_localsplus to
make sure modifications are persisted, but noticed that
changes in the interactive shell weren't being persisted.

I distilled the code we use into the attached file, which
shows that changes aren't being persisted here.  I'm
not an expert on core internals, but I suspect that 
python code "locals()" maps to C code "frame->f_locals",
and we still have the problem that inside functions,
frame->f_locals is a temporary object that is rebuilt on
each access.  From what I've observed, frame->f_localsplus
points to the actual items, and these are the
pointers that need to be changed.


Python tracker <report at bugs.python.org>

More information about the Python-bugs-list mailing list