|I l@ve RuBoard|
9.2 Avoiding lambda in Writing Callback Functions
Credit: Danny Yoo
Between the classic lambda approach and a powerful general-purpose currying mechanism, there's a third, extremely simple way that can come in handy in many practical cases:
class Command: def _ _init_ _(self, callback, *args, **kwargs): self.callback = callback self.args = args self.kwargs = kwargs def _ _call_ _(self): return apply(self.callback, self.args, self.kwargs)
import Tkinter def hello(name): print "Hello", name root = Tk( ) # the lambda way of doing it: Button(root, text="Guido", command=lambda name="Guido": hello(name)).pack( ) # using the Command class: Button(root, text="Guido", command=Command(hello, "Guido")).pack( )
Of course, you can also use a more general currying approach, which lets you fix some of the arguments when you bind the callback, while others may be given at call time (see Recipe 15.8). However, "doing the simplest thing that can possibly work" is a good programming principle. If your application needs some callbacks that fix all arguments at currying time and others that leave some arguments to be determined at callback time, it's probably simpler to use the more general currying approach for all the callbacks. But if all the callbacks you need must fix all arguments at currying time, it may be simpler to forego unneeded generality and use the simpler, less-general approach in this recipe exclusively. You can always refactor later if it turns out you need the generality.
9.2.4 See Also
Recipe 15.8; information about Tkinter can be obtained from a variety of sources, such as Pythonware's An Introduction to Tkinter, by Fredrik Lundh (http://www.pythonware.com/library), New Mexico Tech's Tkinter reference (http://www.nmt.edu/tcc/help/lang/python/docs.html), and various books.
|I l@ve RuBoard|