Evaluating wxPython
Published at 15:26 on 20 May 2026
So, anyhow, I settled on wxPython as my Python GUI framework of choice.
One would think that, given its generally superior programmer interface (it is not even close), wxWidgets and wxPython came after Qt and PySide. Surprisingly, the exact opposite is the case.
My explanation for the mystery is a mixture of groupthink and functionality. Having to continually think about memory management just comes with the territory in C++. So the Qt team, being C++ programmers, didn’t think much of it when designing their Python bindings. It’s all just a natural part of programming, right? Add to that how important smart phones have become, and how Qt supports those (but wxWidgets does not), and you have your answer right there.
Unfortunately, while wxPython is free from the worst braindamage that pervades PySide and PyQt, the package, despite being around for a while and despite having a fairly recent release, doesn’t seem to be very popular and may be on its way to becoming abandonware. What makes me suspect this is that late last Thursday, the wxPython web site started acting up, and as of my typing this is basically completely down. On top of that, I’ve run into a clear bug in the underlying wxWidgets code that has been sitting around unfixed since last February.
Maybe they’re just having a spot of rough luck, but my feeling is that a popular project with lots of active development would probably have a backup site going by now. If they manage to restore service by Friday afternoon, I will probably keep the faith (and even offer to contribute my own efforts), but things are on hold until then.
If it doesn’t come back up, it will probably be time to chalk up another win for .NET. Avalonia certainly has its issues, but they don’t seem to rise to a Qt level of obnoxiousness, and I don’t want to produce something that’s basically obsolete the instant I finish coding it.