On Thu, 28 Jan 2021, 11:18 pm Mark Shannon, <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. 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. > 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/MCRXLN5O5NVOY4WGYLTOSQYSGD2255WB/ Code of Conduct: http://python.org/psf/codeofconduct/
