No, there's only one locals() dict *per stack frame*. So no worries about concurrency.
On Mon, May 27, 2019 at 6:54 AM Richard Damon <rich...@damon-family.org> wrote: > On 5/27/19 9:12 AM, Terry Reedy wrote: > > On 5/27/2019 3:18 AM, Greg Ewing wrote: > >> Chris Angelico wrote: > >>> Except that it does. After calling locals() a second time, the result > >>> of the *first* call will be updated to reflect changes. > >> > >> Yeow. That's *really* unintuitive. There had better be an extremely > >> good reason for this behaviour. > > > > I believe that the situation is or can be thought of as this: there is > > exactly 1 function locals dict. 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. One implication of this is that then you really want ALL > modules to define if they use the locals() function or not, then you get > the question, does this 1 of apply across threads? does a call to locals > in another thread make me lose my locals (or does each thread get its > own version), if that is true then if you might possible be in a > situation where threads are in play you MUST make the copy anyway, and > do it fast enough that the GIL isn't released between the snapshot and > the copy (if possible), > > C made this sort of mistake decades ago for some functions, not thinking > about threads or re-entrancy, and had to create solutions to fix it. Let > us not forget history and thus repeat it. > > Is there a fundamental reason that local needs to keep a single dict, as > opposed to creating a new one for each call? The way it is currently > defined, once it is called, the snapshot will stay forever, consuming > resources, while if a new dict was created, the resource would be > reclaimed after use. Yes, if called twice you end up with two copies > instead of both being updated to the current, but if you WANTED to just > update the current copy, you could just rebind it to the new version, > otherwise you are just forcing the programmer to be making the copies > explicitly. > > -- > Richard Damon > > _______________________________________________ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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
