(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.
_______________________________________________ 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
