views:

113

answers:

4

Let's say I have this :


def a(dict):
  locals().update(dict)
  print size

def b():
  size = 20
  f(locals())

What do I have to do to access the size variable directly from the a function? I know of :


size = dict["size"]

but I think there should be a more direct way. I tried using locals().update(dict) but it didn't work. Is there a betteer way ?

A: 
print size

cannot work, because "size" is not known when the code is compiled. Your code will work if you change it like this:

def a(dict):
    locals().update(dict)
    print locals()["size"]

def b():
    size = 20
    a(locals())

But as the comment to your question already suggests: This is very strange code. I'm very sure that there are better solutions, if you explain what you really want to do.

Achim
A: 

Is this helping you somehow?

def print_size(size=None):
    print(size)

dict = {'size': 'XXL'}
print_size(**dict)
Ionuț G. Stan
+1  A: 

You can use closures to access the scope of another function:

def b():

  def a():
    print size

  size = 20
  a()

The trick is to stack functions which belongs together in each other. This way the inner funtion a can access the local variables of the outer function b.

But I don't know what you're really up to so I'm not sure if this helps.

sebasgo
+2  A: 

The Python compiler optimizes access to local variables by recognizing at compile time whether the barenames a function is accessing are local (i.e., barenames assigned or otherwise bound within the function). So if you code:

def lv1(d):
  locals().update(d)
  print zap

the compiler "knows" that barename zap is NOT local (not assigned in function lv1) and so it compiles code to access it as a global instead -- whatever d contains won't matter.

If you prefer slow and bloated code, you can defeat the optimization by using an exec inside the function -- when the compiler sees the keyword exec, it KNOWS you're trying to make your code as slow, bloated and buggy as possible, and so it cooperates by not optimizing in any way, just about.

So, the following code works as you desire:

def lv1(d):
  exec ""
  locals().update(d)
  print zap

lv1({'zap': 23})

it emits 23 as you want.

I hope it's clear from the above "deadpan humor" that the technique is not recommended, but I'd better spell it out very explicitly: for the dubious syntactic pleasure of writing print zap in lieu of print locals()['zap'], you ARE paying a hefty price in terms of performance. Still, like all sorts of dangerous tools that can be useful in rare use cases for really experienced guru-level programmers who really truly know what they're doing and why, exec is there, available for you to use (or mis-use) at your whim: Python does NOT stand in your way!-)

Alex Martelli
This seems like a hack that really depend on the version of Python that is used. Is there any guarantee that this will continue to work?
Johan
It must work in any compliant Python (1.* or) 2.* implementation; it must not and does not work in any compliant 3.* implementation, as the whole point of making Python 3 was to enable us to break backwards compatibility in such ways. But then, even `print goo` stops working in Python 3 (must be `print(goo)` there), so the similar weakening of `exec` syntax and semantics is hardly a major issue in comparison;-).
Alex Martelli
why is there a bare string sent to `exec`?
Geo
@Geo, it does not matter precisely WHAT string you're `exec`ing -- the mere _presence_ of an `exec` statement without specific dicts in function scope tells the Python compiler (in Python < 3.0) to turn off the usual elementary optimizations (esp. the detection of local variables [[barenames]] that usually makes accessing them, in the function they're in, so much faster than accessing globals). So, you might as well exec an empty string, since you have nothing further to execute, you're JUST making sure the normal optimizations are turned off in this function!
Alex Martelli