[Python-Dev] PEP 558: Defined semantics for locals()

[Steve Holden]

I'm guessing the reason is to remove the overhead of keeping the dictionary
up to date during function execution when no Python code needs access to it.


On Mon, May 27, 2019 at 8:10 PM Richard Damon <Richard at damon-family.org>
wrote:

> On 5/27/19 2:05 PM, Terry Reedy wrote:
> > On 5/27/2019 9:52 AM, Richard Damon wrote:
> >> On 5/27/19 9:12 AM, Terry Reedy wrote:
> >
> >>> I believe that the situation is or can be thought of as this: there is
> >>> exactly 1 function locals dict.
> >
> > per function invocation, or more generally, as Guido said, per stack
> > frame.  This part is obvious to me, but I should have been clearer.
> >
> >>>   Initially, it is empty and
> >>> inaccessible (unusable) from code.  Each locals() call updates the
> >>> dict to a current snapshot and returns it.
> >>>
> >> I had a similar concern, and one BIG issue with it being define this way
> >> is that you get a fundamental re-entrancy problem. If module a uses
> >> locals(), and then calls module b that uses locals(), module a has lost
> >> its usage.
> >
> > No. Sorry about being unclear.
> >
> Ok, if each function invocation gets its own dict, then the reentrancy
> issues go away.
>
> The fact that it isn't the 'active' dict, so you can't use it to modify
> the current state, but also you don't get a fresh copy each time (there
> is a single mutable dict that gets updated) seems to be an odd behavior
> and I can't see where it is an advantage to the user of the function, or
> where that makes it easier on the implementation. (But I could easy be
> missing something).
>
> --
> Richard Damon
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190528/f6983ada/attachment.html>