So why is it “hellish” for JITs if locals() returns a proxy, while frame.f_locals being a proxy is okay?
On Tue, May 28, 2019 at 9:12 PM Nick Coghlan <ncogh...@gmail.com> wrote: > (I'll likely write a more detailed reply once I'm back on an actual > computer, but wanted to send an initial response while folks in the US are > still awake, as the detailed reply may not be needed) > > Thanks for this write-up Nathaniel - I think you've done a good job of > capturing the available design alternatives. > > The one implicit function locals() update case that you missed is in the > accessor for "frame.f_locals", so I think dropping CPython's implicit > update for all Python trace functions would be a clear win (I actually > almost changed the PEP to do that once I realized it was already pretty > redundant given the frame accessor behaviour). > > I'm OK with either [PEP-minus-tracing] or [snapshot], with a slight > preference for [snapshot] (since it's easier to explain). > > The only design option I wouldn't be OK with is [proxy], as I think that > poses a significant potential backwards compatibility problem, and I trust > Armin Rigo's perspective that it would be hellish for JIT-compiled Python > implementations to handle without taking the same kind of performance hit > they do when they need to emulate the frame API. > > By contrast, true snapshot semantics will hopefully make life *easier* for > JIT compilers, and folks that actually want the update() behaviour can > either rely on frame.f_locals, or do an explicit update. > > This would also create a possible opportunity to simplify the fast locals > proxy semantics: if it doesn't need to emulate the current behaviour of > allowing arbitrary keys to be added and preserved between calls to > locals(), then it could dispense with its internal dict cache entirely, and > instead reject any operations that try to add new keys that aren't defined > on the underlying code object (removing keys and then adding them back > would still be permitted, and handled like a code level del statement). > > Cheers, > Nick. > > > -- --Guido (mobile)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
