This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: UnboundLocalError scoping problem with nested functions
Type: behavior Stage: resolved
Components: Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, olau, r.david.murray
Priority: low Keywords:

Created on 2009-11-06 19:23 by olau, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg94994 - (view) Author: Ole Laursen (olau) Date: 2009-11-06 19:23
This works:

def outer(name):
    tmp = name
    def inner():
        print(tmp)
    return inner

outer("foo") # prints "foo"

While the same code with one extra line (setting tmp after printing) 
fails

def outer(name):
    tmp = name
    def inner():
        print(tmp)
        tmp = "hello"
    return inner

outer("foo")()

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in inner
UnboundLocalError: local variable 'tmp' referenced before assignment

and the following works

def outer(name):
    tmp = name
    def inner():
        tmp = "hello"
        print(tmp)
    return inner

outer("foo")() # prints "hello"

Now, I understand there's an interesting issue of assignment binding to 
the inner-most scope. So tmp = "hello" is binding a new variable, not 
changing the outermost tmp. But I should still be able to read tmp, 
right? It looks like some kind of optimizer error.


For the record, this pattern came up in a decorator like this

def deco(x = None):
    def inner(fn):
         if not x:
             x = somedefaultvalue
    
    return inner

which gives the same UnboundLocalError error.
msg95002 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-11-06 21:21
Any assignment causes a value to be local to its current scope.
msg95070 - (view) Author: Ole Laursen (olau) Date: 2009-11-09 11:39
OK, sorry, I was under the impression that the global binding was still 
available (I can't find anything to the contrary here 
http://docs.python.org/reference/simple_stmts.html#assignment-statements 
) but it's obviously using a static definition of scope.

The error message isn't super helpful, though. :) Would it make sense to 
add a "(non-local "tmp" is shadowed)"? I guess that's easy to detect?
msg95096 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2009-11-09 19:15
The relevant section is
http://docs.python.org/reference/executionmodel.html#naming-and-binding.
 Perhaps a cross-reference should be added to the assignment section. 
If you think it should, please open a new issue for that.

I have opened issue 7290 with a suggested improvement to the FAQ entry
that most closely deals with this.  Could you review that and let me
know in that issue if you think it is a worthwhile improvement?
History
Date User Action Args
2022-04-11 14:56:54adminsetgithub: 51525
2009-11-09 19:15:27r.david.murraysetpriority: low

nosy: + r.david.murray
messages: + msg95096

type: compile error -> behavior
stage: resolved
2009-11-09 11:39:09olausetmessages: + msg95070
2009-11-06 21:21:55benjamin.petersonsetstatus: open -> closed

nosy: + benjamin.peterson
messages: + msg95002

resolution: wont fix
2009-11-06 19:23:15olaucreate