Programming Python (51 page)

import sys
from tkinter import *
def quit():                                  # a custom callback handler
print('Hello, I must be going...')       # kill windows and process
sys.exit()
widget = Button(None, text='Hello event world', command=quit)
widget.pack()
widget.mainloop()

Figure 7-11. A button that runs a Python function

Example 7-13. PP4E\Gui\Intro\gui3b.py

import sys
from tkinter import *                        # lambda generates a function
widget = Button(None,                        # but contains just an expression
text='Hello event world',
command=(lambda: print('Hello lambda world') or sys.exit()) )
widget.pack()
widget.mainloop()

For instance,
notice that the
handler
function in the prior section’s
initial code could also refer to
X
directly, because it is a global variable (and would exist by the time
the code inside the handler is run). Because of that, we might make
the handler a one-argument function and pass in just the string
'spam'
in the lambda:

def handler(A):                           # X is in my global scope, implicitly
...use global X and argument A...
X = 42
Button(text='ni',
command=(lambda: handler('spam'))
)

For that matter,
A
could be
moved out to the global scope too, to remove the need for lambda here
entirely; we could register the handler itself and cut out the
middleman.

Although simple in this trivial example, arguments are generally
preferred to globals, because they make external dependencies more
explicit, and so make code easier to understand and change. In fact,
the same handler might be usable in other contexts, if we don’t couple
it to global variables’ values. While you’ll have to take it on faith
until we step up to larger examples with more complex state retention
needs, avoiding globals in callbacks and GUIs in general both makes
them more reusable, and supports the notion of multiple instances in
the same program. It’s good programming practice, GUI or not.

More subtly, notice
that if the button in this example was constructed
inside a
function
rather than at the top level of
the file, name
X
would no longer be
global but would be in the enclosing function’s local scope; it seems
as if it would disappear after the function exits and before the
callback event occurs and runs the lambda’s code:

def handler(A, B):
...use A and B...
def makegui():
X = 42
Button(text='ni', command=(lambda: handler(X, 'spam')))       # remembers X
makegui()
mainloop()   # makegui's scope is gone by this point

Luckily, Python’s enclosing scope reference model means that the
value of
X
in the local scope
enclosing the lambda function is automatically retained, for use later
when the button press occurs. This usually works as we want today, and
automatically handles variable references in this role.

To make such enclosing scope usage explicit, though, default
argument values can also be used to remember the values of variables
in the enclosing local scope, even after the enclosing function
returns. In the following code, for instance, the default argument
name
X
(on the left side of the
X=X
default) will remember object
42
, because the variable name
X
(on the right side of the
X=X
) is evaluated in the enclosing
scope, and the generated function is later called without any
arguments:

def handler(A, B):              # older Pythons: defaults save state
...use A and B...
def makegui():
X = 42
Button(text='ni',
command=(lambda X=X: handler(X, 'spam'))
)

Since default arguments are evaluated and saved when the lambda
runs (not when the function it creates is later called), they are a
way to explicitly remember objects that must be accessed again later,
during event processing. Because tkinter calls the lambda function
later with no arguments, all its defaults are used.

This was not an issue in the original version of this example
because name
X
lived in the global
scope, and the code of the lambda will find it there when it is run.
When nested within a function, though,
X
may have disappeared after the enclosing
function exits.

While they can make some external dependencies more explicit,
defaults are not usually required (since Python 2.2, at least) and are
not used for this role in best practice code today. Rather, lambdas
simply defer the call to the actual handler and provide extra handler
arguments. Variables from the enclosing scope used by the lambda are
automatically
retained, even after the enclosing
function exits.

The prior code listing, for example, can today normally be coded
as we did earlier—name
X
in the
handler will be automatically mapped to
X
in the enclosing scope, and so effectively
remember what
X
was when the button
was made:

def makegui():
X = 42                                                    # X is retained auto
Button(text='ni',
command=(lambda: handler(X, 'spam'))
)   # no need for defaults

We’ll see this technique put to more concrete use later. When
using classes to build your GUI, for instance, the
self
argument is a local variable in
methods, and is thus automatically available in the bodies of lambda
functions. There is no need to pass it in explicitly with
defaults:

class Gui:
def handler(self, A, B):
...use self, A and B...
def makegui(self):
X = 42
Button(text='ni',
command=(lambda: self.handler(X, 'spam'))
)
Gui().makegui()
mainloop()

When using classes, though, instance attributes can provide
extra state for use in callback handlers, and so provide an
alternative to extra call arguments. We’ll see how in a moment. First,
though, we need to take a quick non-GUI diversion into a dark corner
of Python’s scope rules to understand why default arguments are still
sometimes necessary to pass values into nested lambda functions,
especially in GUIs.

Although you may still see defaults used to pass in enclosing
scope references in some older Python code, automatic enclosing scope
references are generally preferred today. In fact, it seems as though
the newer nested scope lookup rules in Python automate and replace the
previously manual task of passing in enclosing scope values with
defaults altogether.

Well, almost. There is a catch. It turns out that within a
lambda (or
def
), references to
names in the enclosing scope are actually resolved when the generated
function is
called
, not when it is created.
Because of this, when the function is later called, such name
references will reflect the latest or final assignments made to the
names anywhere in the enclosing scope, which are not necessarily the
values they held when the function was made. This holds true even when
the callback function is nested only in a module’s global scope, not
in an enclosing function; in either case, all enclosing scope
references are resolved at function call time, not at function
creation time.

This is subtly different from default argument values, which are
evaluated once when the function is
created
, not
when it is later called. Because of that, defaults can still be useful
for remembering the values of enclosing scope variables as they were
when you made the function. Unlike enclosing scope name references,
defaults will not have a different value if the variable later changes
in the enclosing scope, between function creation and call. (In fact,
this is why mutable defaults like lists retain their state between
calls—they are created only once, when the function is made, and
attached to the function itself.)

This is normally a nonissue, because most enclosing scope
references name a variable that is assigned just once in the enclosing
scope (the
self
argument in class
methods, for example). But this can lead to coding mistakes if not
understood, especially if you create functions within a
loop
; if those functions reference the loop
variable, it will evaluate to the value it was given on the
last
loop iteration in
all
the functions generated. By contrast, if you use defaults instead,
each function will remember the
current
value of
the loop variable, not the last.

Because of this difference, nested scope references are not
always sufficient to remember enclosing scope values, and defaults are
sometimes still required today. Let’s see what this means in terms of
code. Consider the following nested function (this section’s code
snippets are saved in file
defaults.py
in the examples package, if you
want to experiment with them).

def simple():
spam = 'ni'
def action():
print(spam)         # name maps to enclosing function
return action
act = simple()              # make and return nested function
act()                       # then call it: prints 'ni'

This is the simple case for enclosing scope references, and it
works the same way whether the nested function is generated with a
def
or a lambda. But notice that
this still works if we assign the enclosing scope’s
spam
variable
after
the
nested function is created:

def normal():
def action():
return spam         # really, looked up when used
spam = 'ni'
return action
act = normal()
print(act())                # also prints 'ni'

As this implies, the enclosing scope name isn’t resolved when
the nested function is made—in fact, the name hasn’t even been
assigned yet in this example. The name is resolved when the nested
function is
called
. The same holds true for
lambdas:

def weird():
spam = 42
return (lambda: spam * 2)       # remembers spam in enclosing scope
act = weird()
print(act())                        # prints 84

So far, so good. The
spam
inside this nested lambda function remembers the value that this
variable had in the enclosing scope, even after the enclosing scope
exits. This pattern corresponds to a registered GUI callback handler
run later on events. But once again, the nested scope reference really
isn’t being resolved when the lambda is run to create the function;
it’s being resolved when the generated function is later
called
. To make that more apparent, look at this
code:

def weird():
tmp = (lambda: spam * 2)        # remembers spam
spam = 42                       # even though not set till here
return tmp
act = weird()
print(act())                        # prints 84

Here again, the nested function refers to a variable that hasn’t
even been assigned yet when that function is made. Really, enclosing
scope references yield the latest setting made in the enclosing scope,
whenever the function is called. Watch what happens in the following
code:

def weird():
spam = 42
handler = (lambda: spam * 2)     # func doesn't save 42 now
spam = 50
print(handler())                 # prints 100: spam looked up now
spam = 60
print(handler())                 # prints 120: spam looked up again now
weird()

Now, the reference to
spam
inside the lambda is different each time the generated function is
called! In fact, it refers to what the variable was set to
last
in the enclosing scope at the time the
nested function is called, because it is resolved at function call
time, not at function creation time.

In terms of GUIs, this becomes significant most often when you
generate callback handlers within loops and try to use enclosing scope
references to remember extra data created within the loops. If you’re
going to make functions within a loop, you have to apply the last
example’s behavior to the loop variable:

def odd():
funcs = []
for c in 'abcdefg':
funcs.append((lambda: c))      # c will be looked up later
return funcs                      # does not remember current c
for func in odd():
print(func(), end=' ')            # OOPS: print 7 g's, not a,b,c,... !

Here, the
func
list simulates
registered GUI callback handlers associated with widgets. This doesn’t
work the way most people expect it to. The variable
c
within the nested function will always be
g
here, the value that the variable
was set to on the final iteration of the loop in the enclosing scope.
The net effect is that all seven generated lambda functions wind up
with the same extra state information when they are later
called.

Analogous GUI code that adds information to lambda callback
handlers will have similar problems—all buttons created in a loop, for
instance, may wind up doing the same thing when clicked! To make this
work, we still have to pass values into the nested function with
defaults in order to save the current value of the loop variable (not
its future value):

def odd():
funcs = []
for c in 'abcdefg':
funcs.append((lambda c=c: c))    # force to remember c now
return funcs                        # defaults eval now
for func in odd():
print(func(), end=' ')              # OK: now prints a,b,c,...

This works now only because the default, unlike an external
scope reference, is evaluated at function
creation
time, not at function call time. It
remembers the value that a name in the enclosing scope had when the
function was made, not the last assignment made to that name anywhere
in the enclosing scope. The same is true even if the function’s
enclosing scope is a module, not another function; if we don’t use the
default argument in the following code, the loop variable will resolve
to the same value in all seven functions:

funcs = []                              # enclosing scope is module
for c in 'abcdefg':                     # force to remember c now
funcs.append((lambda c=c: c))        # else prints 7 g's again
for func in funcs:
print(func(), end=' ')              # OK: prints a,b,c,...

The moral of this story is that enclosing scope name references
are a replacement for passing values in with defaults,
but
only
as long as the name in the enclosing scope will not
change to a value you don’t expect after the nested function is
created. You cannot generally reference enclosing scope loop variables
within a nested function, for example, because they will change as the
loop progresses. In most other cases, though, enclosing scope
variables will take on only one value in their scope and so can be
used freely.

We’ll see this phenomenon at work in later examples that
construct larger GUIs. For now, remember that enclosing scopes are not
a complete replacement for defaults; defaults are still required in
some contexts to pass values into callback functions. Also keep in
mind that classes are often a better and simpler way to retain extra
state for use in callback handlers than are nested functions. Because
state is explicit in classes, these scope issues do not apply.
The next two sections cover this in
detail.