Nathaniel Smith added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30744> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
