This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Mark.Shannon, arigo, belopolsky, benjamin.peterson, ncoghlan, njs, vstinner, xdegaye, xgdomingo, yselivanov
Date 2017-09-11.05:18:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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
            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:16ncoghlansetrecipients: + ncoghlan, arigo, belopolsky, vstinner, benjamin.peterson, njs, xdegaye, Mark.Shannon, yselivanov, xgdomingo
2017-09-11 05:18:16ncoghlansetmessageid: <>
2017-09-11 05:18:16ncoghlanlinkissue30744 messages
2017-09-11 05:18:15ncoghlancreate