Programming Python (50 page)

In
gui1c.py
(shown in
Example 7-4
),
I started packing labels without assigning them to names.
This works, and it is an entirely valid coding style, but because it
tends to confuse beginners at first glance, I need to explain why it
works in more detail here.

In tkinter, Python class objects correspond to real objects
displayed on a screen; we make the Python object to make a screen
object, and we call the Python object’s methods to configure that screen
object. Because of this correspondence, the lifetime of the Python
object must generally correspond to the lifetime of the corresponding
object on the screen.

Luckily, Python scripts don’t usually have to care about managing
object lifetimes. In fact, they do not normally need to maintain a
reference to widget objects created along the way at all unless they
plan to reconfigure those objects later. For instance, it’s common in
tkinter programming to pack a widget immediately after creating it if no
further reference to the widget is required:

Label(text='hi').pack()                        # OK

This expression is evaluated left to right, as usual. It creates a
new label and then immediately calls the new
object’s
pack
method to
arrange it in the display. Notice, though, that the Python
Label
object is temporary in this expression;
because it is not assigned to a name, it would normally be garbage
collected (destroyed and reclaimed) by Python immediately after running
its
pack
method.

However, because tkinter emits Tk calls when objects are
constructed, the label will be drawn on the display as expected, even
though we haven’t held onto the corresponding Python object in our
script. In fact, tkinter internally cross-links widget objects into a
long-lived tree used to represent the display, so the
Label
object made during this statement
actually is retained, even if not by our code.
^[
29
]

In other words, your scripts don’t generally have to care about
widget object lifetimes, and it’s OK to make widgets and pack them
immediately in the same statement without maintaining a reference to
them explicitly in your code.

But that does not mean that it’s OK to say something like
this:

widget = Label(text='hi').pack()               # wrong!
...use widget...

This statement almost seems like it should assign a newly packed
label to
widget
, but it does not do
this. In fact, it’s really a notorious tkinter beginner’s mistake. The
widget
pack
method packs the widget
but does not return the widget thus packed. Really,
pack
returns the Python object
None
; after such a statement,
widget
will be a reference to
None
, and any further widget operations
through that name will fail. For instance, the following fails, too, for
the same reason:

Label(text='hi').pack().mainloop()             # wrong!

Since
pack
returns
None
, asking for its
mainloop
attribute generates an exception (as
it should). If you really want to both pack a widget and retain a
reference to it, say this instead:

widget = Label(text='hi')                      # OK too
widget.pack()
...use widget...

This form is a bit more verbose but is less tricky than packing a
widget in the same statement that creates it, and it allows you to hold
onto the widget for later processing. It’s probably more common in
realistic scripts that perform more complex widget configuration and
layouts.

On the other hand, scripts that compose layouts often add some
widgets once and for all when they are created and never need to
reconfigure them later; assigning to long-lived names in such programs
is pointless and
unnecessary.

Example 7-10. PP4E\Gui\Intro\gui2.py

import sys
from tkinter import *
widget = Button(None, text='Hello widget world', command=sys.exit)
widget.pack()
widget.mainloop()

Example 7-11. PP4E\Gui\Intro\gui2b.py

from tkinter import *
root = Tk()
Button(root, text='press', command=root.quit).pack(side=LEFT)
root.mainloop()

Even with a GUI this
simple, there are many ways to lay out its appearance with
tkinter’s constraint-based
pack
geometry manager. For example, to center the button in its window, add
an
expand=YES
option to the button’s
pack
method call in
Example 7-11
. The line of changed
code looks like this:

Button(root, text='press', command=root.quit).pack(side=LEFT, expand=YES)

This makes the packer allocate all available space to the button
but does not stretch the button to fill that space. The result is the
window captured in
Figure 7-7
.

Figure 7-7. pack(side=LEFT, expand=YES)

If you want the button to be given all available space
and
to stretch to fill all of its assigned space
horizontally, add
expand=YES
and
fill=X
keyword arguments to the
pack
call. This will create the scene
in
Figure 7-8
.

Figure 7-8. pack(side=LEFT, expand=YES, fill=X)

This makes the button fill the whole window initially (its
allocation is expanded, and it is stretched to fill that allocation). It
also makes the button grow as the parent window is resized. As shown in
Figure 7-9
, the button
in this window does expand when its parent expands, but only along the X
horizontal axis.

Figure 7-9. Resizing with expand=YES, fill=X

To make the button grow in both directions, specify both
expand=YES
and
fill=BOTH
in the
pack
call; now resizing the window makes the
button grow in general, as shown in
Figure 7-10
. In fact, for more
fun, maximize this window to fill the entire screen; you’ll get one very
big tkinter button indeed.

Figure 7-10. Resizing with expand=YES, fill=BOTH

In more complex displays, such a button will expand only if all of
the widgets it is contained by are set to expand too. Here, the button’s
only parent is the
Tk
root window of
the program, so parent expandability isn’t yet an issue; in later
examples, we’ll need to make enclosing
Frame
widgets expandable too. We will revisit
the packer geometry manager when we meet multiple-widget displays that
use such devices later in this tutorial, and again when we study the
alternative
grid
call
in
Chapter 9
.