Home Original page

[Python-Dev] [PEP 558] thinking through locals() semantics

Guido van Rossum guido at python.org
Wed May 29 00:29:15 EDT 2019 
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 <ncoghlan at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190528/821083fa/attachment.html>
More information about the Python-Dev mailing list