Eric Promislow <er...@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 http://bugs.activestate.com/show_bug.cgi?id=87417 ------------------------------------------------- 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, etc. 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 <rep...@bugs.python.org> <http://bugs.python.org/issue9274> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
