On Sat, 30 Jan 2021 at 10:30, Nick Coghlan <ncogh...@gmail.com> wrote: > On Sat, 30 Jan 2021, 12:13 am Mark Shannon, <m...@hotpy.org> wrote: >> 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
Reviewing the code again, I'd misremembered how the draft implementation works - right now, reads are relying on the snapshot being up to date. > 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. For now, I have a PR adding this as an open question: https://github.com/python/peps/pull/1787/files Given the performance benefit of being able to more reasonably drop the implicit call to `PyFrame_LocalsToFast()`, I'm mostly convinced that switching reads to pull from the frame if possible is the right thing to do, even if it reduces the amount of code that can be inherited without modification from MappingProxyType. The API compatibility concerns would mean the extra mapping store still needed to stick around, but it would only be used for: * providing backwards compatibility for the `PyEval_GetLocals()` and C-level `f_locals` interfaces * reading and writing names that don't have entries in the `fast_refs` mapping * writing shadow updates for names in the `fast_refs` mapping Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/ZKS4NG6HNOSNHJVUYHKHNSWT747FFPFP/ Code of Conduct: http://python.org/psf/codeofconduct/
