Related to this reply here. Locals' doc here.
The docs mention that the dictionary should not change, not sure what it means but would locals()
be applicable in lab-reports where data won't change, for example in measurements?
From Dive into Python
locals is a function that returns a dictionary, and here you are setting a value in that dictionary. You might think that this would change the value of the local variable x to 2, but it doesn't. locals does not actually return the local namespace, it returns a copy. So changing it does nothing to the value of the variables in the local namespace.
In the CPython interpreter, local variables can come from a number of places (the details of this are not important, but it has to do with how variables are stored for closures). The locals()
function gathers up the names and values from all these places, to give you convenient access to them all in one place, but since it doesn't know where a given variable came from, it can't put it back. In other words, it's a bad idea because it doesn't work.
In certain cases, the call to locals() returns values collected from multiple sources, rather than a pointer to the local scope.
Example: When inside a function call, locals() returns a combination of the global scope and the scope local to the function. In this case, modifying the locals() output won't make any changes to the local scope because it's essentially using an island. It seems like the only cases where it does work are cases where its output is the same as the output of globals().
So, in other words, you either want to use globals(), or find a different way to achieve the same goal.
Modification is a bad idea because the documentation (which you link) explicitly says not to:
You don't need any more reason than that.
If you are using it in a way that doesn't modify any variables, then you'll be fine, but I'd question the design and see if there's a better way to do what you want.
In the specific example you link, locals is actually globals(), as you use it in the global scope of a module. This very specific use works now and, though I expect it to continue to work just as with globals, you might as well just use globals instead.
An even cleaner solution is probably, without knowing the rest of your design, to use a regular ol' dictionary for your variables; then use data["x"] = value instead of globals()["x"] = value.