tags:

views:

337

answers:

4

locals is a built in function that returns a dictionary of local values. The documentation says:

Warning

The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter.

Unfortunately, exec has the same problem in Python 3.0. Is there any way round this?

Use Case

Consider:

@depends("a", "b", "c", "d", "e", "f")
def test():
    put_into_locals(test.dependencies)

depends stores the strings provided in its arguments in a list test.dependences. These strings are keys in a dictionary d. I would like to be able to able to write put_into_locals so that we could pull the values out of d and put them into the locals. Is this possible?

A: 

I'm not sure if it is subject to the same restrictions, but you can get a direct reference to the current frame (and from there, the local variables dictionary) through the inspect module:

>>> import inspect
>>> inspect.currentframe().f_locals['foo'] = 'bar'
>>> dir()
['__builtins__', '__doc__', '__name__', '__package__', 'foo', 'inspect']
>>> foo
'bar'
dcrosta
This is exactly the same as locals(); `inspect.currentframe().f_locals is locals()` is true.
Glenn Maynard
+1  A: 

This isn't possible. I think this is to allow for performance optimizations later on. Python bytecode references locals by index, not by name; if locals() was required to be writable, it could prevent interpreters from implementing some optimizations, or make them more difficult.

I'm fairly certain you're not going to find any core API that guarantees you can edit locals like this, because if that API could do it, locals() wouldn't have this restriction either.

Don't forget that all locals must exist at compile-time; if you reference a name that isn't bound to a local at compile-time, the compiler assumes it's a global. You can't "create" locals after compilation.

See this question for one possible solution, but it's a serious hack and you really don't want to do that.

Note that there's a basic problem with your example code:

@depends("a", "b", "c", "d", "e", "f")
def test():
    put_into_locals(test.dependencies)

"test.dependencies" isn't referring to "f.dependencies" where f is the current function; it's referencing the actual global value "test". That means if you use more than one decorator:

@memoize
@depends("a", "b", "c", "d", "e", "f")
def test():
    put_into_locals(test.dependencies)

it'll no longer work, since "test" is memoize's wrapped function, not depends's. Python really needs a way to refer to "the currently-executing function" (and class).

Glenn Maynard
+3  A: 

I just tested exec and it works in Python 2.6.2

>>> def test():
...     exec "a = 5"
...     print a
...
>>> test()
5

If you are using Python 3.x, it does not work anymore because locals are optimized as an array at runtime, instead of using a dictionary.

When Python detects the "exec statement", it will force Python to switch local storage from array to dictionary. However since "exec" is a function in Python 3.x, the compiler cannot make this distinction since the user could have done something like "exec = 123".

http://bugs.python.org/issue4831

To modify the locals of a function on the fly is not possible without several consequences: normally, function locals are not stored in a dictionary, but an array, whose indices are determined at compile time from the known locales. This collides at least with new locals added by exec. The old exec statement circumvented this, because the compiler knew that if an exec without globals/locals args occurred in a function, that namespace would be "unoptimized", i.e. not using the locals array. Since exec() is now a normal function, the compiler does not know what "exec" may be bound to, and therefore can not treat is specially.

Unknown
I think it is pretty conclusive that it is just not possible
Casebash
@Casebash, it probably is possible, it just requires byte code hacks or Python 2.x
Unknown
Okay, I'll leave this question unresolved for now
Casebash
@Casebash: you might not want to hold your breath. Python byte codes are not very well documented.
Unknown
I'll probably look at it myself some day. ATM, I really am not going to get enough utility out of it to justify the effort
Casebash
+3  A: 

The local variables are modified by assignment statements.

If you have dictionary keys which are strings, please don't also make them local variables -- just use them as dictionary keys.

If you absolutely must have local variables do this.

def aFunction( a, b, c, d, e, f ):
    # use a, b, c, d, e and f as local variables

aFunction( **someDictWithKeys_a_b_c_d_e_f )

That will populate some local variables from your dictionary without doing anything magical.

S.Lott
just what I was thinking; you could also dynamically create a function; see help(types.FunctionType)
gatoatigrado
This is an interesting idea. However, there are many applications in which the dictionary actually contains many other variables (that are not needed by `aFunction()`), which makes the current definition of `aFunction()` break. A useful generalization is: `aFunction(a, b, c, d, e, f, **kwargs)`.
EOL
@EOL: Extra parameter variables make a function break? That's hard to imagine. A few extra variables should be -- well -- just variables. A function that breaks because of a few extra variables has a remarkably poor design. It would be better to fix this function.
S.Lott
@S. Lott: Let me rephrase my point: what breaks is having the signature `def aFunction(a, b, c, d, e, f)` when `someDictWithKeys_a_b_c_d_e_f` contains more keys than these few variables, which is a typical situation when performing complex scientific calculations (the whole calculation uses more variables than most of the functions it calls). As I pointed out, `def aFunction(a, b, c, d, e, f, **kwargs)` is a convenient way of addressing this situation.
EOL
@EOL: I can't see how this "breaks". There are simply extra variables which are unused. How is that "broken"?
S.Lott
@S. Lott: just run the code of your answer (which I upvoted) with `aFunction(**{'a': 0, 'b': 1, 'c': 2, 'd': 3, 'e': 4, 'f': 5, 'g': 6})` and this will precisely show why my remark can be useful to StackOverflow readers. In real-life scientific calculations, dictionaries typically hold more variables than what is sent individually to each function called.
EOL
@EOL: "Typically"? That's just bad design. "Breaks"? That's just bad design. Are you suggesting that bad design can be tolerated? Is that your definition of "breaks"? "has a design that's fatally flawed"? I think "breaks" is the wrong word. I think "supports proper debugging" might be what you're talking about. I cannot seriously imagine software so poorly written that "typically" functions have the wrong set of arguments provided to them.
S.Lott