Known bugs

In practice, the term 'known bug' seems to refer to a bug that no-one can be bothered to fix. The bugs I list here are not central to my purpose for writing these scripts (which was to compare tkinter and wxPython). Fixing them is left as an exercise for the reader.

SLOCs

The two scripts are about the same size.

$ wc my*Calc.py
120  351 3891 myCalc.py
 89  191 2396 myTkCalc.py
 85  195 2306 myWxCalc.py

imports

The Tkinter and wx packages are imported slightly differently.

>>> from Tkinter import *
>>>

but

>>> from wx import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute '__DocFilter'
>>> import wx
>>>

Note that from module import * is discouraged, especially on Windows and Mac platforms [7].

buttonPress()

Because of the design of the superclass (see above), I have had to overload only five methods, and these show only minor idiomatic differences.

buttonPress() is the method bound to key-press events and, although the two versions differ only a little, it demonstrates the different approach to key events in the two toolkits (see Table 3).

Table 3: buttonPress(self, event) in MyTkCalc and MyWxCalc

TkCalc                                       WxCalc

keysym2label = {'plus': '+',                 keyCode2label = {wx.WXK_RETURN: '=',
                'minus': '-',                                 wx.WXK_BACK: 'C',
                'asterisk': '*',                              wx.WXK_DELETE: 'C',
                'period': '.',                                17: 'OFF' }
                'slash': '/',
                'equal': '=',
                'Return': '=',
                'Delete': 'C',
                'BackSpace': 'C',
                'q': 'OFF' }

def buttonPress(self, event):                def buttonPress(self, event):
    k = event.keysym                             c = event.GetKeyCode()
                                                 k = chr(c)
    if k not in '1234567890':                    if k not in '1234567890+-*/.=':
        k = self.keysym2label.get(k)                 k = self.keyCode2label.get(c)
    self.keyAction(k)                            self.keyAction(k)

In Tkinter, event objects of any kind have a standard set of attributes [8] including (for keyboard events) char, keycode and keysym. Keycode is a code relating to the key pressed (not the ASCII character code); char and keysym both return strings - for alphanumerics both return the string of the key pressed, for other keys (e.g., '=', <left-ctrl-key>, or Return) keysym returns a description (i.e., 'equal', 'Control_L', 'Return'). Note that two-key combinations (e.g., shift-8) count as two keypress events. Keycode will give the same code for both events; keysym and char show the effect of the combinations (i.e., with shift-8 keysym returns 'Shift_R' then 'asterisk').

In WxPython, there are three different kinds of keypress events [9]: wx.EVT_KEY_DOWN, wx.EVT_KEY_UP and wx.EVT_CHAR. These event types have the same methods, the relevant one here being GetKeyCode(), which returns the ASCII value of the key pressed, or a wxWidgets constant [10] for non-alphanumerics. However, wx.EVT_CHAR.GetKeyCode() shows combination effects (like keysym above), while wx.EVT_KEY_DOWN/UP.GetKeyCode() do not.

__init__()

The __init__() method is where the two calculators differ most. See Table 4 for a side-by-side comparison.

Table 4: __init__(self) in TkCalc and WxCalc

TkCalc                                                                               WxCalc

def __init__(self):                                                                  def __init__(self):
    AbstractCalculator.__init__(self)                                                    AbstractCalculator.__init__(self)
                                                                                         self.app = wx.PySimpleApp()
    Frame.__init__(self)
    self.pack(expand=NO, fill=NONE)                                                      wx.Frame.__init__(self, None, -1, "Simple WxP Calc")
    self.master.title('Simple Tk Calc')                                                  sizer = wx.BoxSizer(wx.VERTICAL) # Main vertical sizer
    self.master.resizable(0,0)
                                                                                         self._display = wx.TextCtrl(self, -1, '',
    self._display = StringVar()                                                                                      style = wx.TE_READONLY | wx.TE_RIGHT)
    self._display.set('0')                                                               self.display = '0'
    Entry(self, justify=RIGHT, relief=SUNKEN,                                            sizer.Add(self._display, 0, wx.EXPAND) # Add to main sizer
          disabledforeground='black',
          disabledbackground='white',                                                    gsizer = wx.GridSizer(4, 4)
          state=DISABLED,                                                                for row in self.keyLayout:
          textvariable=self._display).pack(side=TOP, expand=YES, fill=BOTH)                  for key in row:
                                                                                                 b = wx.Button(self, -1, key)
    for row in self.keyLayout:                                                                   b.Bind(wx.EVT_BUTTON,
        rowFrame = Frame(self)                                                                          lambda e, k=key: self.keyAction(k))
        for key in row:                                                                          b.SetFocus()
            Button(rowFrame, text=key,                                                           gsizer.Add(b)
                   command=lambda k=key: self.keyAction(k),                              sizer.Add(gsizer, 1, wx.EXPAND)
                   width=4).pack(side=LEFT, expand=NO, fill=NONE)                        self.SetSizer(sizer)
        rowFrame.pack(side=TOP, expand=YES, fill=BOTH)                                   sizer.Fit(self)

    self.bind('<KeyPress>', self.buttonPress)                                            self.Bind(wx.EVT_CHAR, self.buttonPress)
    self.focus_set()
                                                                                         self.Show()
    self.mainloop()                                                                      self.app.MainLoop()

The toolkits differ in the way they add widgets to the main frame. Both use the first parameter of a widget's __init__() for the widget's parent. However, wxPython uses an explicit sizer to place widgets inside the parent (i.e., with sizer.Add() methods); tkinter uses the widget's pack() method to place it. Similarly, in Tkinter commands can be bound to widgets as part of their initialisation, while wxPython calls a separate Bind method (see the loop to set up the keys in Table 4).

Because the documentation was not 100% comprehensive (see below) and because I decided to limit the time spent on these GUIs, there are some minor details which remain mysterious:

• For the calculator display, I found it necessary to use read-only text entry boxes to disable the user from directly entering text into the display (i.e., a disabled Entry on tkinter, and a READONLY TextCtrl on wxPython). The documentation points to Label or Panel widgets as being more appropriate, but I couldn't get these to work properly (e.g. tkinter Label insisted on central justification, whatever I specified in initialisation).
• In wxPython, the lambda function bound to each Button - lambda e, k=key: self.keyAction(k) - must carry the first argument e for the event object, even though it's not used (the tkinter lambda is otherwise identical).

Once the GUI has been initialised, both toolkits use a mainloop method to set it going, and waiting for events. Here again, wxPython is slightly more complicated. In wxPython the mainloop is not run by the GUI object itself, but by a separate application object (in WxCalc, the application object wx.PySimpleApp is attached to the calculator at the beginning of __init__()). This helps abstract overall management of the application away from particular software objects or GUI widgets.

documentation

Each toolkit has a book devoted to it published by Manning: tkinter has "Python and Tkinter Programming" [11]; wxPython has "wxPython in Action" [12]. The two books are interestingly different in style. I found Garyson's book on tkinter quite inspiring about the way I wrote python in general, beyond GUI coding. The wxPython book is a huge FAQ: it's well-written and very useful, but not an inspiring read. Conversely, the tkinter book has 250 pages of fairly comprehensive appendices and a 30 page index; the wxPython book does not attempt to be comprehensive, has no appendices and only six pages of index.

For wxPython, the book is nice to get started, but you really have to use the online documentation [13]. This is comprehensive /but/ it's not for wxPython: the wxPython online docs page is actually a frame wrapped around the wxwidgets online docs page (n.b.: true up to 03/01/08). Translating between C++ and python is a bit of a drag but fairly trivial - for example, the class and method names and parameters and all the semantics are the same.

Tkinter also has good online documentation [14]. I haven't used it much, as [11] answers most of my questions.

The documentation for neither system was fully reliable, so I occasionally had to use the absolute default and spend some time with Google. This seems to be par for the course with most software these days, open or closed source.