Message301856
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. |
|
Date |
User |
Action |
Args |
2017-09-11 05:18:16 | ncoghlan | set | recipients:
+ ncoghlan, arigo, belopolsky, vstinner, benjamin.peterson, njs, xdegaye, Mark.Shannon, yselivanov, xgdomingo |
2017-09-11 05:18:16 | ncoghlan | set | messageid: <1505107096.07.0.805668008883.issue30744@psf.upfronthosting.co.za> |
2017-09-11 05:18:16 | ncoghlan | link | issue30744 messages |
2017-09-11 05:18:15 | ncoghlan | create | |
|