Repository navigation
locals() behaviour differs when tracing is in effect #51332
Description
Activity
andbj commented
on Oct 8, 2009 andbjmannequinMannequinAuthorRunning the attached script shows that locals() behaves differently
depending on whether sys.settrace() is active.This does not occur when calling locals() in the global scope, only when
used inside functions.The same is thing is true of the frame's f_locals attribute. This
attribute is a copy of the local variables in the frame, because the
internal storage of these variables is a raw C array for faster access.
This copy is only synchronized back when a tracing function returns, so
as to allow implementing a debugger.>>> def f(): ... a = 1 ... l = sys._getframe().f_locals ... b = 2 ... return l ... >>> f() {'a': 1}
The above optimization (raw C array for faster access of local
variables) is not done at the global scope, and therefore locals() at
that scope give you direct access to the variables' internal store
(which is, actually, the module's __dict__).>>> import __main__ >>> __main__.__dict__ is locals() True
So there's no bug here right? It's even documented.
andbj commented
on Oct 8, 2009 andbjmannequinMannequinAuthorIt's documented that "The contents of this dictionary should not be
modified; changes may not affect the values of local variables used by
the interpreter."The script does the opposite. Perhaps an addition to the documentation?
"The contents of this dictionary may not be affected by local variables
used by the interpreter".I think the doc is clear enough if one reads and believes it. The main
doc is "Update and return a dictionary representing the current local
symbol table." That pretty clearly says that subsequent changes to the
local symbol table may make the dict out of date until updated by a
subsequent call.ITSM this could use more clarification. It is subtle and baffling. I'm struggling to come up with sentences to make it clearer, though.
I wrote about this here: http://nedbatchelder.com/blog/201211/tricky_locals.html A reader suggested this addition to the docs, which I like:
"Multiple invocations within the scope update and return the same dictionary instance. When a trace function is in effect, this dictionary is updated after every statement."
techtonik commented
on Dec 26, 2012 techtonikmannequinMannequinI'm 3rd to vote for reopening this issue to clarify documentation or to fix (read below).
== Why it is important to fix
-
First personal user story. Until I saw the localstest.py I couldn't figure out what all locals() definitions are talking about. Dictionary, that is a copy, but the copy is sporadically updated when nobody is using in background. It is a weird dictionary with inconsistent behavior placed at a rather critical part of the language.
-
Second personal story. I probably run into the same bug in bpo-16781. Probably, because I still don't understand what really happens. It is only a suspicion, and it is bad because with my experience I'm supposed to know what happens, but I never had the time to dig deeper until now.
-
locals() is referenced in exec/execfile() docs for the explanation of arguments. Magic of locals() multiplied by exec.execfile() gives a next level of headache when you need to resolve this. Add settrace() to the formula to awake a hater in you.
exec/execfile() are used in Python-based scripting tools (such as SCons), in trace scripts and when Python is embedded as a scripting language. Coding on this level should be easy to make more interesting tools to appear.
== Fix Idea
- Is it possible to rename locals() to _locals(), and leave user visible API function local() for an object that updates itself every time it is accessed?
-
techtonik commented
on Dec 27, 2012 techtonikmannequinMannequinAfter a day of meditation I've come to the following definition for locals():
locals() return a dictionary that serves as a cache for current local symbol table. This cache is updated every time locals() is called or when a trace function is active.
I agree now that the doc should be clearer (and this issue reopened). For one thing, the exact CPython behavior is an implementation issue rather than a language requirement. Which is to say, its behavior is allowed but not required. I believe an implementation *could* use dicts for function local namespaces. Synchronization would not then be an issue.
I will try to work up a concrete suggested replacement.
techtonik commented
on Feb 3, 2013 techtonikmannequinMannequinAny progress on that? After a month I am inclined that this behavior should be fixed, not only documented. The correct documentation is:
NOTE: The variable returned by locals() is sporadically updated by core interpreter.
Anatoly, please stop playing with the headers. It is meaningless and irritating, especially when you set them wrong. The 3.5 choice is for issues that will *not* apply before then. An example is actually making a change warned about in a deprecation warning. 3.2 will soon see its last regular bugfix release. The main purpose of the headers is to help developers develop and apply a patch. The secondary purpose is serve as history and to inform users.
As I explained in my email to you
- The OP meant for this to be a code bug report.
- This was properly closed as an invalid bug report. So there will be no code patch. So the headers have no use except as history.
- I do believe the doc should be changed, *and* I believe it should be a new issue. If I do open one, I will try to remember to add it here as superseder.
techtonik commented
on Mar 27, 2013 techtonikmannequinMannequinAttached localtest2.py where an empty locals() call changes behavior.
--- localtest.py Wed Mar 27 19:48:06 2013 +++ localtest2.py Wed Mar 27 19:45:19 2013 @@ -3,6 +3,7 @@ def X(): l = locals() i = "foo" + locals() print("Is 'i' in stored locals()? ", ('i' in l))
print("Running normally")
Calling locals() updates the dict, just as documented.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: