Hi Sven,
On 04/02/2021 9:06 am, Sven R. Kunze wrote:
On 03.02.21 23:37, Nick Coghlan wrote:
No, PEP 558 doesn't remove it, it enhances it to be a live view of the
frame state instead of an inconsistently updated snapshot.
As long as it is possible to **write** to existing keys to **add new
keys** to frame.f_locals, I am actually quite happy.
Out of interest, why would you want to add new keys to the locals of a
function frame?
The function will never be able to use those values.
The potential incompatibility Mark is referring to is the fact that
even optimised frames currently allow writing to arbitrary keys in
frame.f_locals and making the bound values visible to the locals()
builtin and other consumers of frame.f_locals.
For PEP 558, it's an open question as to whether that behaviour will
become limited to the PyEval_GetLocals() backwards compatible C API,
with the updated Python frame API instead throwing KeyError for
attempts to write to unknown keys on optimised frames.
So, it seems the restricting behavior is for special cases only (not
including with-statements which I would care about).
I just wanted to mention that accessing problematic parts of the
interpreter's internals can be quite helpful when doing concept-proofing
or working the way through until a "batteries-included" solution exist.
Thanks,
Sven
_______________________________________________
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/M7N3SNYPNPAAL5TF2BFMUCYWAT6WVARU/
Code of Conduct: http://python.org/psf/codeofconduct/
