On Tue, 24 Aug 2021 at 01:57, Guido van Rossum <gu...@python.org> wrote: > On Mon, Aug 23, 2021 at 8:46 AM Mark Shannon <m...@hotpy.org> wrote: >> Can we avoid describing the C structs in any of these PEPs? >> >> It confuses readers having Python attributes and "C-level attributes" >> (C struct fields?). >> It also restricts the implementation unnecessarily. >> >> (E.g. the PyFrameObject doesn't have a `f_locals` field in 3.11: >> https://github.com/python/cpython/blob/main/Include/cpython/frameobject.h#L7) > > > I'd be happy to. Nick's PEP still references it (and indeed it is very > confusing) and I took it from him. And honestly it would be nice to have a > specific short name for it, rather than circumscribing it with "an internal > dynamic snapshot stored on the frame object " :-)
https://github.com/python/peps/pull/2060/files switches over to calling it the "frame value cache" in PEP 558, since that's essentially what it is on optimised frames (even today). An unrelated issue that came up while working on that update is something that affects both PEPs: calling "proxy.clear()" is *super weird* if we make it work the same way as PyEval_LocalsToFast() works today. Specifically, it can reach out and clear cells in outer frames, including the __class__ cell used by zero-arg super(). I can't see anyone being super upset if we decide to change that and say that proxy.clear() leaves free variables alone, and only clears local variables and cells owned by that particular frame. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/FJYJJWZBZNAZBW2UDWGSNFCVB26JINNU/ Code of Conduct: http://python.org/psf/codeofconduct/
