
Keys that are not defined as local or closure variables on the underlying
Hi Nick - as for: frame are still written to the f_locals cache on optimised frames. This means current behavior will be kept, right? the f_locals cache is persistent across descending calls from the current frame? To be more specific - I have a somewhat toy package (though I've used it on serious code on occasion prior to having the "walrus" operator) which allows one to keep an anonymous stack on the current running frame and operate on it with "push", "pop", "dup", etc... calls. The stack is a list referenced in a "hidden" variable created on the first call to "push". From my reading that would still work, right? On Sun, 18 Jul 2021 at 03:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
Hi folks,
It's been a long time coming, but I've finally made enough progress on the reference implementation that I think it's time to ask Nathaniel to pronounce on the current iteration of PEP 558 (Defined semantics for locals()).
The rendered version is up at https://www.python.org/dev/peps/pep-0558/, and I've included the plain text version below.
For those that are reading the PEP for the first time, the gist is:
* standardise on Python 3.10 behaviour *except* that locals() at function scope returns a fresh snapshot every time instead of a reference to the frame level state cache * make the Python level frame.f_locals on optimised frames a write-through proxy that keeps both the real fast locals storage and the C level f_locals state cache up to date * add new C APIs that allow C code to explicitly request the semantics the client code actually wants ("behave like the Python locals() builtin", "always make a copy", "always provide a read-only view") * soft-deprecate the legacy PyEval_GetLocals() API (while ensuring it still works) * use the new features to significantly improve the performance of code execution tracing hooks implemented in Python
For those that remember reading older versions of the PEP, the key changes relative to the last discourse thread (back in late 2019/early 2020) are:[...]