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

[Nick Coghlan]

(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190529/7582b2bd/attachment.html>