- 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