GUI toolkit(s) status

Kevin Walzer kw at
Fri Nov 21 15:13:38 CET 2014

On 11/20/14, 11:34 PM, Terry Reedy wrote:
> A possible solution for Tk is to replace the non-C Tcl parts of TK with
> Python (or the CPython API functions as needed for speed).  I have no
> idea how horrendous a project creating Py/Tk would be.

It would be very horrendous. See Perl/Tk as the example. They ripped out 
the Tcl interpreter and interfaced directly with Tk's C API. The result 
was a rigid, inflexible binding that was never ported to the Mac 
(because it required a C implementation) and could never be easily 
updated to take advantage of new features in Tk, because again it 
required a C implementation. Perl-Tk still exists, but more modern 
bindings like ActiveState's Tkx module have restored the Tcl 
interpreter, giving you access to all Tk advances and platforms "for free."

Apart from the ease of updating Tk features, from a design standpoint I 
think this is the right call. There may be a little extra overhead in 
having an extra interpreter embedded, but that is what Tcl was 
originally designed for: embedding. It handles this requirement more 
easily and with less pain than most languages. I think that's why Tk 
became the default GUI binding of choice for other scripting languages.


Kevin Walzer
Code by Kevin/Mobile Code by Kevin

More information about the Python-list mailing list