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 njs
Recipients Mark.Shannon, arigo, belopolsky, benjamin.peterson, ncoghlan, njs, vstinner, xgdomingo, yselivanov
Date 2017-06-29.05:46:23
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).

Maybe I was unclear...? my question is why you prefer locals-making-a-copy over locals-and-f_locals-for-function-frames-return-proxy-objects. It seems to me that both of these proposals eliminate the "tracing or not?" global state dependence (right?), so this can't be a reason to prefer one over the other. And the latter additionally eliminates the distinction between modules/classes/exec/eval and functions/generators/coroutines, while also avoiding introducing a distinction between locals() and f_locals.
Date User Action Args
2017-06-29 05:46:24njssetrecipients: + njs, arigo, ncoghlan, belopolsky, vstinner, benjamin.peterson, Mark.Shannon, yselivanov, xgdomingo
2017-06-29 05:46:24njssetmessageid: <>
2017-06-29 05:46:24njslinkissue30744 messages
2017-06-29 05:46:23njscreate