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, xgdomingo, yselivanov
Date 2017-06-28.04:52:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I like it because it categorically eliminates the "tracing or not?" global state dependence when it comes to manipulation of the return value of locals() - manipulating that will either always affect the original execution namespace immediately (modules, classes, exec, eval), or always be a completely independent snapshot that can never lead to changes in the original name bindings (functions, generators, coroutines).

As a result, the locals() documentation updates for issue #17960 wouldn't need to mention trace functions at all.

Instead, the only folks that would need to worry about potentially unexpected updates to the internal state of functions, generators, and coroutines when tracing is in effect would be those accessing frame.f_locals directly. That state dependence can then be documented specifically as part of the f_locals documentation, and users of that attribute can make their own copy if they want to ensure that their subsequent mutations definitely can't affect the original namespace, even when tracing is in effect.
Date User Action Args
2017-06-28 04:52:12ncoghlansetrecipients: + ncoghlan, arigo, belopolsky, vstinner, benjamin.peterson, njs, Mark.Shannon, yselivanov, xgdomingo
2017-06-28 04:52:12ncoghlansetmessageid: <>
2017-06-28 04:52:12ncoghlanlinkissue30744 messages
2017-06-28 04:52:12ncoghlancreate