[Python-Dev] PEP 558: Defined semantics for locals() (original) (raw)
Guido van Rossum guido at python.org
Mon May 27 11:06:25 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 ]
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 <Richard at 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 at 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/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20190527/2400c3ac/attachment.html>
- 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 ]