On Sat, 30 Jan 2021, 12:13 am Mark Shannon, <m...@hotpy.org> wrote: > Hi > > It is a lot more complex, because you need to worry about coherency. > With a direct proxy coherency is not an issue. >
For things in the frame, it *is* a direct proxy - reads pull from the frame object, and writes go to both the frame object and the mapping: https://github.com/python/cpython/pull/3640/files#diff-7b8cef249e5cca077d30de4e428a6bde6b9b803464e790e9cffa7e052e19efddR1315 The technical pay-off from having the mapping there is that most read-only dict operations are handled by the existing MappingProxyType. If you drop the mapping, then you lose any code sharing, and have to implement the full mapping API from scratch, instead of just the mutation and single key lookup parts. You also reduce compatibility with the status quo, since writes to unknown keys will fail rather than being stored solely in the mapping section, and there's also no way to preserve the "PyEval_GetLocals()" C API, which is expected to return a borrowed reference to a plain Python dict stored in the C level "f_locals" field on the frame struct. The cache coherency issues on the bulk mapping APIs this perpetuates also aren't any worse than those on the locals() built-in itself: they'll see the state as of the last snapshot update rather than the live state on the frame (which may not exist any more if the proxy outlives the underlying frame). Given the resulting C API compatibility break and the loss of code sharing, I don't think it's a net win to drop the extra storage. Cheers, Nick. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BZAMC7NXQGYY7WGDAOUT3TYXBDP7OZCT/ Code of Conduct: http://python.org/psf/codeofconduct/
