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-09.13:04:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1504962263.48.0.00677687930106.issue30744@psf.upfronthosting.co.za>
In-reply-to
Content
After drafting PEP 558, briefly chatting about it to Guido, and sleeping on the topic, I'm wondering if there might be answer that's simpler than any of the alternatives consider so far: what if PyFrame_FastToLocals added the *cell objects* to f_locals for any variables that the compiler would access using LOAD/STORE_DEREF (rather than LOAD/STORE_FAST), and then PyFrame_LocalsToFast only wrote back the entries for variables that used LOAD/STORE_FAST?

That would be enough to fix the reported problems (since PyFrame_LocalsToFast would always leave closure variables alone in both the function defining the closure and the ones referencing it), and a trace hook that actually *wanted* to update the closure references could write to the "cell_contents" attribute on the cell of interest.
History
Date User Action Args
2017-09-09 13:04:23ncoghlansetrecipients: + ncoghlan, arigo, belopolsky, vstinner, benjamin.peterson, njs, xdegaye, Mark.Shannon, yselivanov, xgdomingo
2017-09-09 13:04:23ncoghlansetmessageid: <1504962263.48.0.00677687930106.issue30744@psf.upfronthosting.co.za>
2017-09-09 13:04:23ncoghlanlinkissue30744 messages
2017-09-09 13:04:22ncoghlancreate