In possession of wxPython in Action and with an itch to scratch, hacked together wxDebug (thanks to Python hosting) – a front end for viewing Xdebug profiling output, the UI design being inspired by (but by no means as good as) WinCacheGrind. A screenshot…

wxdebug screenshot

The real mission was an excuse to do something a little more in depth with wxPython – this is some notes on that.


Figure something needs saying here, given I’m usually waffling on about PHP plus the fact Sitepoint has yet to make Python a “first class language”, despite Django

First disclaimer: I’m no master of Python – self taught, used for mainly hobbyish stuff. Criticisms / amendments appreciated.

Python is a general purpose (vs. PHP which is designed for web apps) dynamic programming language. It’s roughly the same age as Perl but, cutting a long story short, only started picking up widespread popularity in the last 5 years (I guess). Recently somewhat ruffled by the rise of Ruby / Rails.

There’s a lot one can say about Python but really it’s value is best indicated by some “external lifesigns” like…

  • Google has enough of it’s code written in Python that they figured they’d better hire the creator.
  • Microsoft felt the need to hire Jim Hugunin to support his effort to write Python.NET, called IronPython (this is logically equivalent to something like PHP’s Phalanger). Jim is also wrote most of Jython (Python for Java) I believe.
  • Although the main Python distribution is written in C (commonly called CPython) and there’s the aforementioned .NET and Java implementations, there’s also PyPy – “an implementation of Python, written in Python, that can interpret itself” (quote from here). As far as I know that makes Python the only one of the “big five” dynamic languages (Perl, Python, PHP, Ruby, Javascript) to have become “self aware”. One potential gain there (as I understand it) is you can have code that does stuff like optimize / regenerate itself to tune for the data it’s actually processing or the environment it’s running under.
  • Performance-wise, compared to the other popular dynamic languages, Python effectively comes out as the “winner” in this language shootout (OK – lies and stats but still interesting the number of times I comes out ahead of Perl – more than I’d expected).
  • Nokia chose Python as the preferred dynamic language for their S60 phones.
  • Brendan Eich wants, and Mark Hammond is bringing Python and XUL close together in Mozilla (read – an alternative to Javascript for writing Firefox extensions).
  • Mark Shuttleworth / Canonical have been actively promoting Python, related to what they’re doing with Ubuntu and things like bzr.
  • Some things that get requested, but that PHP doesn’t, Python does, such as threads and the ability to convert python scripts into standalone windows programs.

What’s also nice about Python is the general impression (when you look at other peoples code) of a community that knows how to code.

On the downside I’d argue the Python community has yet to see itself from the outside – how accessible is it to beginnners? For example I think if you asked a beginner to locate the documentation on methods provided by a dictionary type, you’d be surprised by how many fail to get to this page (or visit it and move on – “classdict?”) [side note – lots of good examples of standard Python APIs in use here] Perhaps it would be worth hooking up with someone like Sean on the PHP documentation team and devising a way for users to add notes to the Python docs?

Otherwise, Python hasn’t picked up the kind of following in help sites (forums etc) that PHP has, although those that exist seem better focused and more likely to result in informed response. Fundamentally, I’d still argue PHP is better suited for web applications (perhaps there’s room for a Py2PHP here via PyPy?) but in terms of “right tool for job”, there are many areas where PHP is the wrong tool…

That said Python is well worth the effort. It’s not a far cry from PHP, if that’s where you’re coming from. A Byte of Python makes a good “straight” introduction if you’ve already done some programming. Dive into Python is for the more experienced but also gives you the fastest insight into Python’s power as a language. Otherwise there’s also a Non-Programmers Tutorial For Python. Finally, for PHP developers, would recommend examining the code here and here in detail, for a leg up.


Building desktop GUIs has become somewhat less cool in the last five years, especially given AJAX and the rebirth of Javascript. Despite that, think there’s still a value, as a web developer, in being able to write simple desktop GUIs to help support web applications and make users lives easier. Given wxPython plus Python’s excellent Windows extensions (COM etc.), it’s a powerful combination to help automate things for those users refusing to budge from Word or Excel.

But if you’d asked what some of the top requirements were for a GUI toolkit, around the time Java + AWT / Swing were getting lots of attention, you’d probably get some or more of the following bullets…

  • Responsive (GUI reacts to users)
  • Native look and feel (Windows apps need to look like Windows apps)
  • Easy / quick to develop in
  • Cross platform (i.e. there’s at least a chance of being able to get this Win32 app to run under Linux and MacOS).

Although it would have been bigger news five years ago, wxPython essentially delivers all of the above.

wxPython is a Python “wrapper” around wxWidgets : “An open source C++ GUI framework to make cross-platform programming child’s play.”. The wxWidgets project is about as old as Linux I believe and it’s probably safe to label it as “mature”. Conceptually, wxPython is something like PHP-GTK but much more mature by comparison (as is Python itself) with the added advantage of wxWidgets providing a native look and feel on whatever OS it’s running on (which PHP-GTK doesn’t).

In the Python community, the main barrier wxPython has had to overcome is the learning curve. If you already knew you’re way around wxWidgets, no problem, but for everyone else it’s probably something like being given command of a 747 having leant how to fly a glider. Enter the book…

wxPython in Action

Not going to do a long review – you’ll find one here and an interview with Robin Dunn here (co-author and lead developer).

Mini review: it’s a good book. The book’s main objective seems to be enablement – to help readers grasp the key wx.concepts, required to be self sufficient. With myself as Guinea pig, think it succeeds in that aim: I’m now wx.dangerous ;) Note I wasn’t a complete wxPython newbie – had written one small but useful utility but nothing really serious (i.e. I hadn’t got as far as using sizers) – the book has definately the tipping point to help me grasp wxPython. It’s also very readable – Robin Dunn’s confidence as lead wxPython developer combined with Noel Rappins experience as an educator play well together.

There are things, in retrospect, which I find myself wishing the book had included e.g. coverage of more widgets (like the Notebook), some reference appendices and more on application design (MVC, MVP etc.). At the same time, there’s the “Good design is what you can leave out” point of view which I think applies here – I expect “wxPython in Action” will survive future wxPython releases. If you need it, there’s book on wxWidgets (as in C++), which is far more comprehensive from a reference point of view but still largely applicable to wxPython.


The plan with wxDebug was to enjoy building a prototype – which means saying “who cares?” to things like documentation, unit tests or spending excessive effort on clean abstractions. It shamefully attempts to rip off Wincachegrind’s UI design (although it doesn’t go so far as MDI yet), for which I apologise to Hendy Irawan.

So some random thoughts based on experience hacking wxDebug together (and after having read the book)…

  • Although the book gives you enough examples of the most common widgets, expect to need to Google or trawl the wxPython source code occasionally, for examples and stuff like style constants.
  • It’s worth browsing around the API docs – one thing the book could have done better is simply advertising available components by way of short description. For example, stumbling on wx.FileConfig by chance (not in the book) made this much easier.
  • Did all the hacking under Windows. Which in retrospect was probably a mistake, because trying wxDebug under Ubuntu for the first time, a few days ago, showed it to be pretty badly broken. wxPython / wxWidgets is cross platform not platform independent (i.e. it’s do-able but needs doing). The impression I get is wxWidgets regards Windows to be the first class citizen (but perhaps I’m wrong) so it’s probably smarter to develop under Linux (GTK) / OS X, it being less pain to begin on the weaker cousin there then move to Windows.
  • Taskcoach remains the best code base I’ve seen to learn how to do wxPython well (then, in my case, disregard and continue hacking). It’s probably the best place to go once you’re through wxPython in Action and are looking for more insight. The ActiveGrid IDE is interesting but seems to have a very different style for glueing components together (based on the notion of services) – may be smarter in the long run but doesn’t seem gel well with what everyone else is doing with wxPython.
  • Other than that wxDebug didn’t “just work” under Linux, encountered no major bugs / holes in wxPython – it’s remarkably stable and mature from all I’ve seen. One minor issue, after being “clever” and replacing my static TreeCtrl with a virtual tree control, was a node that had an unusually large number of children caused the app to crash while appending them all – yet to determine why. In general was able to make pretty much even progress, productivity-wise.
  • Having enjoyed hacking, I’ve also re-discovered, for the nth time, the importance of unit tests and useful abstractions. Taskcoach provides a good example of how to unit test a wxPython app. wxDebug makes no real attempt to seperate views from controllers, and that’s quickly turning into a mess and needs addressing. That said I’d recommend avoiding MVC or otherwise, while getting started, as it’s important to understand where the abstractions are actually useful, otherwise you’ll be battling your own code pretty quickly, rather than learning about wxPython.

Anyway, wxDebug is available here in binary form for Windows (extract someone and run wxdebug.exe – thanks py2exe) – it’s a working prototype that offers absolutely zero benefit over Wincachegrind, other than perhaps novelty. Undecided right now as to whether I’m going to continue with it – there’s plenty of improvement to do, from replacing the use of lists with tuples and removing the use of regexes in the parser, to writing unit tests, getting it working under Max OS X and Linux, using MDI frames etc. etc. For now, no bug reports please – it’s just a prototype.