Also removes the exec() and eval() caveats on the reference implementation
(those have been migrated now, albeit not using a code structure that we
would genuinely want to merge).
When updating the PEP to specify independent snapshots for locals()
at function scope, I missed this reference to the old semantics
that returned a direct reference to the dynamic internal snapshot.
* Switch to independent snapshots at function scope
* New public C API, PyEval_Get_PyLocals(), that matches the updated locals() builtin
* At function scope, PyEval_GetLocals() returns the internal shared mapping from inside the proxy (returning a borrowed reference means this API can't offer the new independent snapshot semantics)
- new design discussion section to cover the requirement that the
semantics of locals() itself at function scope be left alone
- propose a C level API that exactly matches Python level
frame.f_locals semantics
- other minor text formatting and wording updates
Changing the frame API semantics based on whether or not a
tracing function is active is tricky to implement and hard
to document clearly, so this simplifies the proposal by
instead having the frame API always expose a write-through
proxy at function scope, and restricting the dynamic
snapshot behaviour to the locals() builtin.
It turns out that *any* write-back based design has
inherent flaws that make it difficult to build a source
debugger that reliably allows mutation of function local
variables.
So this switches to Nathaniel's suggested write-through
proxy idea, but constrains it to only applying when a
trace hook is installed. This means the official language
level semantics can just use the simpler model where
rebinding function local variables via locals() simply
isn't possible - only folks already working with frames
and trace functions will need to be aware of the semantics
of the write-through proxy.
We should be able to resolve the reported problems just
by changing how trace hooks work, rather than making
any fundamental changes to locals() or frame.f_locals.
- new open questions around how storage and updates
will work
- note that we definitely *don't* want to return the
write-through proxy from locals() at function scope
Nick Coghlan
Guido van Rossum