Nick Coghlan added the comment:
The same way the dis module does: by looking at the names listed in the various
code object attributes.
If it's listed in co_cellvars, then it's a local variable in the current frame
that's in a cell because it's part of the closure for a nested function.
If it's listed in co_freevars, then it's a nonlocal closure reference.
Otherwise, it's a regular local variable that just happens to be holding a
reference to a cell object.
So if all we did was to put the cell objects in the frame.f_locals dict, then
trace functions that supported setting attributes (including pdb) would need to
be updated to be cell aware:
def setlocal(frame, name, value):
if name in frame.f_code.co_cellvars or name in frame.f_code.co_freevars:
frame.f_locals[name].cell_contents = value
else:
frame.f_locals[name] = value
However, to make this more backwards compatible, we could also make it so that
*if* a cell entry was replaced with a different object, then
PyFrame_LocalsToFast would write that replacement object back into the cell.
Even with this more constrained change to the semantics frame.f_locals at
function level, we'd probably still want to keep the old locals() semantics for
the builtin itself - that has lots of string formatting and other use cases
where having cell objects suddenly start turning up as values would be
surprising.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
