Hi Nick,
On 29/01/2021 1:21 pm, Nick Coghlan wrote:
On Thu, 28 Jan 2021, 11:18 pm Mark Shannon, <m...@hotpy.org
<mailto:m...@hotpy.org>> wrote:
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.
Do you know of any tools do that? It seems highly unlikely to me.
In fact tool authors are asking for less state, not more:
https://bugs.python.org/issue42197
(for performance, rather than correctness reasons, I should note)
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.
"keep it working" implies that it works now. It doesn't.
https://bugs.python.org/issue30744
The extra implementation complexity beyond what's already needed to cope
with closure cells also isn't that much.
It is a lot more complex, because you need to worry about coherency.
With a direct proxy coherency is not an issue.
https://bugs.python.org/issue30744 shows that the interactions between
stateful local caches, nonlocals, and concurrency is complex and likely
to be buggy. If you are going to substitute one stateful construct for
another, then you need to provide evidence that it won't introduce new bugs.
Cheers,
Mark.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/Y7MAAIETRGYRJQ3GI6V75BCUCZXXEVGE/
Code of Conduct: http://python.org/psf/codeofconduct/
