Tkinter and WCK (was Re: How come wxPython isn't in the standard library?)

[Jeff Shannon]

Jon Perez wrote:

> I think there's another reason not to standardize on
> wxPython and it's that its API is not at all pythonic.
> It reminds me too much of a C++ API.


Indeed, one of wxPython's design criteria is that it remains fairly 
close to the underlying C++ API -- it is explicitly a fairly thin 
wrapper, not a complete retooling.  (Though there are several retoolings 
built on top of wxPython, notably PythonCard.) 

I think that, despite the sometimes awkwardness for Python programmers, 
this is a laudable goal.  For one, it means that it's that much easier 
to combine Python and C++ in a single wxPython/wxWidgets multilanguage 
application.  For another, considering that wxPython is essentially a 
one-man project, it means that Robin can spend more time exposing 
functionality and less time hiding syntax, so that overall wxPython ends 
up being more powerful than it would otherwise. ;)

On the other hand, I *do* agree that the non-Pythonic API does make for 
a barrier in including wxPython in the standard library.  The initial 
learning curve for wxPython is rather steeper than that for Tkinter 
(though it isn't at all bad if one already has C++ GUI programming 
experience).  Especially when starting from zero, it's easier to figure 
out how to get a simple GUI running under Tkinter.  The downside of 
Tkinter is that it is, in general, less flexible and less powerful than 
wxPython -- simple stuff is easier in Tkinter, but complex stuff is 
generally harder. 

Personally, I much prefer using wxPython.  (But then, I did play around 
with C/C++ Windows programming long before I discovered Python.)  
However, I can also see that the Tkinter toolkit is more appropriate for 
standard-lib usage than wxPython is.  And really, it's not like it's all 
that difficult to install both Python and wxPython when distributing an 
application...

Jeff Shannon
Technician/Programmer
Credit International