Nathaniel Smith <n...@pobox.com> added the comment: I guess I should say that I'm still confused about why we're coming up with such elaborate schemes here, instead of declaring that f_locals and locals() shall return a dict proxy so that from the user's point of view, they Always Just Work The Way Everyone Expects.
The arguments against that proposal I'm aware of are: 1) Implementing a full dict-like mapping object in C is tiresome. But your proposal above also requires doing this, so presumably that's not an issue. 2) We want to keep the current super-complicated and confusing locals() semantics, because we like making life difficult for alternative implementations (PyPy at least exactly copies all the weird details of how CPython's locals() works, which is why it inherited this bug), and by making the language more confusing we can encourage the use of linters and boost Python's Stackoverflow stats. ...I guess my bias against this argument is showing :-). But seriously, if we want to discourage writing to locals() then the way to do that is to formally deprecate it, not go out of our way to make it silently unreliable. 3) According to the language spec, all Python implementations have to support locals(), but only some of them have to support frame introspection, f_locals, debugging, and mutation of locals. But... I think this is a place where the language spec is out of touch with reality. I did a quick survey and AFAICT in practice, Python implementations either support *both* locals() and f_locals (CPython, PyPy, Jython, IronPython), or else they support *neither* locals() nor f_locals (MicroPython -- in fact MicroPython defines locals() to unconditionally return an empty dict). We could certainly document that supporting writes through locals() is a quality-of-implementation thing CPython provides, similar to the prompt destruction guarantees provided by refcounting. But I don't think implementing this is much of a burden -- if you have enough introspection metadata to get the list of locals and figure out where their values are stored in memory (which is the absolute minimum to implement local s()), then you probably also have enough metadata to write back to those same locations. Plus debugger support is obviously a priority for any serious full-fledged implementation. So the original write-through proxy idea still seems like the best solution to me. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30744> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
