Hi Nick - as for:
> Keys that are not defined as local or closure variables on the underlying 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?
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:[...]