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, gvanrossum, ncoghlan, njs, vstinner, xdegaye, xgdomingo, yselivanov
Date 2017-10-13.11:32:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507894355.66.0.213398074469.issue30744@psf.upfronthosting.co.za>
In-reply-to
Content
I'll also note there's a simpler reason the namespace object exposed at the function level can't just be a write-through proxy for the underlying frame: references to frame.f_locals may outlive the frame backing it, at which point we really do want it to be a plain dictionary with no special behaviour, just as it is for regular execution frames. 

(Think "return locals()" as the last line in a helper function, as well as variants like "data = locals(); data.pop('some_key'); return data")

That means that no matter what, we need to snapshot the frame locals the when frame.f_locals is requested. The question then becomes:

- when we do we update the contents of cell references? (this is what's buggy right now when a trace function is installed)
- when do we update ordinary local variables? (this isn't broken, so we want to avoid changing it)

Providing write-through support *just* for cells should thus make it possible to fix the buggy interaction between cells and trace function, while minimising the risk of any unintended consequences affecting regular function locals.
History
Date User Action Args
2017-10-13 11:32:35ncoghlansetrecipients: + ncoghlan, gvanrossum, arigo, belopolsky, vstinner, benjamin.peterson, njs, xdegaye, Mark.Shannon, yselivanov, xgdomingo
2017-10-13 11:32:35ncoghlansetmessageid: <1507894355.66.0.213398074469.issue30744@psf.upfronthosting.co.za>
2017-10-13 11:32:35ncoghlanlinkissue30744 messages
2017-10-13 11:32:35ncoghlancreate