At the start of this chapter, I mentioned that Tkinter is Python’s interface to the Tk GUI library, originally written for the Tcl language. To help readers migrating from Tcl to Python and to summarize some of the main topics we met in this chapter, this section contrasts Python’s Tk interface with Tcl’s. This mapping also helps make Tk references written for other languages more useful to Python developers.
In general terms, Tcl’s command-string view of the world differs widely from Python’s object-based approach to programming. In terms of Tk programming, though, the syntactic differences are fairly small. Here are some of the main distinctions in Python’s Tkinter interface:
Widgets are created as class instance objects by calling a widget class.
Parents are previously created objects that are passed to widget-class constructors.
Options are constructor or config
keyword arguments or indexed
keys.
Widget operations (actions) become Tkinter widget class object methods.
Callback handlers are any callable objects: function, method, lambda, and so on.
Widgets are extended using Python class inheritance mechanisms.
Interfaces are constructed by attaching objects, not by concatenating names.
Variables associated with widgets are Tkinter class objects with methods.
In Python, widget creation commands (e.g., button
) are Python class names that start
with an uppercase letter (e.g., Button
), two-word widget operations (e.g.,
add command
) become a single method
name with an underscore (e.g., add_command
), and the “configure” method can
be abbreviated as “config,” as in Tcl. In Chapter 9, we will also see that
Tkinter “variables” associated with widgets take the form of class
instance objects (e.g., StringVar
,
IntVar
) with get
and set
methods, not simple Python or Tcl
variable names. Table 8-2
shows some of the primary language mappings in more concrete
terms.
Table 8-2. Tk-to-Tkinter mappings
Operation | Tcl/Tk | Python/Tkinter |
---|---|---|
Creation | Frame .panel | panel = Frame( ) |
Masters | button .panel.quit | quit = Button(panel) |
Options | button .panel.go -fg black | go = Button(panel, fg='black') |
Configure | .panel.go config -bg red | go.config(bg='red') go['bg'] = ‘red’ |
Actions | .popup invoke | popup.invoke( ) |
Packing | pack .panel -side left -fill x | panel.pack(side=LEFT, fill=X) |
Some of these differences are more than just syntactic, of course. For instance, Python builds an internal widget object tree based on parent arguments passed to widget constructors, without ever requiring concatenated widget pathname strings. Once you’ve made a widget object, you can use it directly by reference. Tcl coders can hide some dotted pathnames by manually storing them in variables, but that’s not quite the same as Python’s purely object-based model.
Once you’ve written a few Python/Tkinter scripts, though, the coding distinctions in the Python object world will probably seem trivial. At the same time, Python’s support for object-oriented techniques adds an entirely new component to Tk development; you get the same widgets, plus Python’s support for code structure and reuse.
18.191.62.122