Closure gotcha (with Python)

Do you know what a closure is? Basically, it’s a function created at runtime that references variables defined in a outer scope. For example:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer

printer = make_number_printer(5)
printer()

The function make_number_printer receives a number and returns a function which, when called, prints that same number. It’s not the most useful function in the world, but it does show how closures work. In this case, the number_printer function is a closure, because it references the variable n which is in an outer scope (of the make_number_printer function).

My intention here, though, it’s not to explain what closures are but to show a property of them which may cause some confusion (and made me spent quite some time hunting for a bug caused by it). What does this code prints when run?

printer_lst = []
for i in xrange(10):
    def number_printer():
        print i
    printer_lst.append(number_printer)

for printer in printer_lst:
    printer()

It loops between 0 and 10 creating a number_printer function and appending it to a list. Then it loops through the functions of the list, calling them. You would expect it to print the numbers 0 to 9, right?

Wrong! It prints the number 9 ten times.

The problem is that most people (including me, before learning this) think that closures work by evaluating the variables in the outer scope and storing their values to use when necessary. But actually they keep an reference to those variables, and if their contents change, the closure will use the new value. Since our variable i stores the value 9 after the closures are created, that is the value they will print. This happens even if the variable i goes out of scope after the closures are created (e.g., if the first for were inside a function).

So how to solve this? You can move the creation of the closure to another function, like this:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer

printer_lst = []
for i in xrange(10):
    printer_lst.append(make_number_printer(i))

for printer in printer_lst:
    printer()

Here the closure will reference the variable n, which has different instances for each different closure created. Another alternative is to use a somewhat contrived Python “feature” which is the fact that default parameter values are evaluated when the function is defined and not when they are called:

printer_lst = []
for i in xrange(10):
    def number_printer(x=i):
        print x
    printer_lst.append(number_printer)

for printer in printer_lst:
    printer()

When def number_printer(x=i): is run, the variable i is evaluated and its value is saved in the function definition; so, each time the function is defined (i.e., the closure is created), the current value of i is “frozen”.

If somebody is thinking, “but I’ll never run into this situation”, here is a little more real example (which actually happened to me when I was coding a Flash game, which uses ActionScript). Basically it’s the same code above and has the same issue:

class Button:
    #This is a dummy Button class; suppose
    #it's part of a GUI library and for some reason
    #you can't subclass it

    def __init__(self):
        self.listener = None

    def set_click_listener(self, fn):
        self.listener = fn

    def on_click(self):
        self.listener()

#Create 10 buttons...
buttons = [Button() for i in xrange(10)]
#And suppose the buttons are added to the GUI after

#Set the listeners to the click event.
#The number of buttons may change in the future
#and all of them have the same code, the
#only difference is the button index. So it's better
#to do this within a loop.
for i in xrange(10):
    def on_click():
        #Suppose there is something more useful here
        print i
    buttons[i].set_click_listener(on_click)

#Simulate a click in each button
for j in xrange(10):
    buttons[j].on_click()

2 comments

  1. I bumped into this gotcha today and your post gives me a clear, well written explanation.

    The “closure factory” solution is quite straightforward. But I wouldn’t have thought of the keyword arguments workaround, which is concise but a bit cryptic. The kind of thing I’d leave a comment for in my code.

    It’s kind of funny how one common gotcha (how default values are being evaluated) can be used as a workaround for another gotcha.

  2. Hi,

    thanks for this good explanation. I spent a few hours trying to find my bug and I finally used a debugger… then it was easy to see that the value was not the expected one. I wish I had used the debugger earlier!

Leave a comment

Your email address will not be published. Required fields are marked *