[Python-Dev] PEP 558: Defined semantics for locals() (original) (raw)
Richard Damon Richard at Damon-Family.org
Mon May 27 15:08:55 EDT 2019
- Previous message (by thread): [Python-Dev] PEP 558: Defined semantics for locals()
- Next message (by thread): [Python-Dev] PEP 558: Defined semantics for locals()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] PEP 558: Defined semantics for locals()
- Next message (by thread): [Python-Dev] PEP 558: Defined semantics for locals()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]