Hi Nick,
Regarding `f_locals` PEP 558 states:
"""
Instead of being a direct reference to the internal dynamic snapshot
used to populate the independent snapshots returned by locals(),
frame.f_locals will be updated to instead return a dedicated proxy type
(implemented as a private subclass of the existing
types.MappingProxyType) that has two internal attributes not exposed as
part of the Python runtime API:
* mapping: an implicitly updated snapshot of the function local
variables and closure references, as well as any arbitrary items that
have been set via the mapping API, even if they don't have storage
allocated for them on the underlying frame
* frame: the underlying frame that the snapshot is for
"""
This seems rather complex, and consequently fragile.
I fear that this is just going to result in different bugs, rather than
fixing the bugs it proposes to fix.
Why not just make `f_local` a direct view on the underlying frame?
It would be simpler to understand, more robust, and should perform better.
The concern I have with the simplification is that I don't know what would break if trace hooks lost the ability to stash additional state that the compiler doesn't know anything about in f_locals.
Rather than trying to assess how common such usage is, and whether we care about breaking any use cases that people have for it, I instead elected to just keep it working.
The extra implementation complexity beyond what's already needed to cope with closure cells also isn't that much.
Cheers,
Nick.