Do other Python GUI toolkits require this?

Diez B. Roggisch deets at
Mon Apr 23 16:33:57 CEST 2007

> I had originally thought that learning PyObjC might preclude me from
> having to learn Objective-C, but that seems not to be the case. I have
> previously found the same to be true with PyQt and wxPython--not knowing
> the toolkits as they are implemented in C++ is a serious handicap. I've
> even found this to be the case with Tkinter: understanding the Tcl
> implementation of Tk (which I do, because I am also a Tcl developer) is
> a huge advantage.
> Am I wrong to conclude that, if you want to do GUI programming in
> Python, then some level of proficiency with another language is not just
> recommended, but almost required? This is the case at least in my
> experience. When I first started learning Python a couple of years ago,
> I spun my wheels with it for months, because I couldn't figure out where
> to get started with GUI programming. Finally I set Python aside and took
> up Tcl/Tk for awhile--its simplicity in building GUI's is more
> beginner-friendly. (No "there's more than one way to do it"--there's
> only one way to do it, and that's Tk.)
> Now, coming back to Python with the Tk model of GUI development burned
> in my brain, I appreciate the breadth of functions that Python
> supports--but I still find myself "dropping down into Tcl" (!) to
> assemble elements of my GUI's--either to write a Python wrapper, or
> figure out how to implement something in pure Python.
> I understand the argument for Python having lots of bindings to
> different GUI toolkits. If you are already proficient with a GUI toolkit
> in a compiled language (Gtk, wxWidgets, Cocoa, Qt) then presumably
> switching to Python will speed up your development--learning Python is
> easy if you already know C++, for instance, and usually the Python
> bindings are just a "thin wrapper" over the compiled bits. But if you
> come to Python from the other direction--you're a relative beginner and
> you want to learn GUI programming without the complexities of compiled
> languages--then it's a lot harder to get started, ironically. Even
> Tkinter is a challenge for someone who doesn't know Tcl. The basics are
> easy enough--buttons, menus, labels, images--but doing anything
> sophisticated, such as trees, column views, drag-and-drop, and so on,
> requires extensions that may or may not be implemented in Python.

I personally can't conclude with your conclusions :)

Some background: I've started with Tcl/Tk as a scripting language precisely
because of Tk - I liked the easy GUI creation, the layout management, and
it was available for Unix/Linux, my OS of choice.

So when I discovered Python about 7 or 8 years ago, I certainly had the
right mindset for Tk. So, I was able to create GUIs in Tkinter, yet it
never felt very comfortable - it just has too much Tclisms in there for my

So for GUI-development, I moved on to Qt - and simply loved it. I do have
some C++-skillz, although these are somewhat rusty. And all I needed them
for was reading the excellent reference Qt-documentation. Just the
class-docs, not examples!

The last step then was PyObjC. I bought a mac roughly two years ago, and
immediately got interested in GUI-development there. I've never done a
single bit of ObjectiveC before, and even though I now have some few
classes done (mainly for interfacing with parts of OS X or other libraries
that weren't exposed to python, e.g. CIImage and CGImage processing), I
wouldn't say that I'm an ObjectiveC-programmer. 

The hardships for me with PyObjc stemmed from the unawareness and
unfamiliarity with the specifics of GUI-development under the mac in
general. E.g. the concepts of NIBs, NIB-classes, bundles and the like.

Now admittedly I'm not a totally fair comparison to you for judging the
matters at hand - I had a fair amount of exposure to different languages
before and while learning python. But especially for PyObjC I can say that
I became productive pretty fast without having to actually do serious or
even not so serious ObjectiveC-development. 

I'd rather say that using a gui-toolkit usually requires to adapt to
whatever concepts that toolkit has implemented. And certainly there are
some of these that are influenced by the language the toolkit has been
developed for. But for example ObjectiveC and Python both allow for dynamic
dispatch - thus lots of the design decisions would have been the same. And
as ObjecC and Cocoa heavily rely on NSArray and NSDictionary, which the
bridge has good marshalling code for, using python's lists & dicts is
natural and easy.

In Qt OTOH they implemented their dynamic dispatch themselves - but using
slots and signals is easy as cake as well. To me at least :)


More information about the Python-list mailing list