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: series of lamdas in loop sets the paramater on all calls to that of the last call
Type: behavior Stage:
Components: IDLE, Tkinter, Windows Versions: Python 2.6
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: alan.hoover, benjamin.peterson
Priority: normal Keywords:

Created on 2010-04-01 18:26 by alan.hoover, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (2)
msg102120 - (view) Author: alan hoover (alan.hoover) Date: 2010-04-01 18:25
Background:
building a screen using Tkinter based on information from a database to let user take action on the database rows.  I don't know how many rows there will be, so I'm storing the widgets in arrays for each column.

Code:
for row in getDBrows():
    self.buttons.append(Tkinter.Button(self,text='UnLoad it', command=lambda :self.unload(row[0])))

Problem:
When executing the above code, all the buttons have the key to the database table that belongs to the last row.  I found a work around -- by moving the call to create the button (containing the lambda) to a separate function and call that function to create the button instead of creating the button directly, the buttons then make their callback with a correct database key.

Workaround:
for row in getDBrows():
    self.buttons.append(self.buildbutton(row[0]))
.
.
def buildbutton(self,key):
    return Tkinter.Button(self,text='UnLoad it', command=lambda: self.unload(key))

When using the workaround code instead of the original code, the button
for each row has the appropriate key to the database.

Speculation:
It acts like the lambda definitions don't get solidified until the containing block exits; at that time, the lambda definition(s) get locked in with the current value of the variable getting passed into the lambda as a parameter.  By moving the lambda call to a different block (separate function), the lambda gets "locked" when that block (function) exits instead of when the containing block (loop) exits.
msg102122 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-04-01 18:28
This is a defined behavior of closures.
History
Date User Action Args
2022-04-11 14:56:59adminsetgithub: 52530
2010-04-01 18:28:48benjamin.petersonsetstatus: open -> closed

nosy: + benjamin.peterson
messages: + msg102122

resolution: not a bug
2010-04-01 18:26:00alan.hoovercreate