Terry Reedy <tjre...@udel.edu> wrote: > Tk itself is purely a gui package -- abstract widgits, geometry placers > to make them visible, and an event system to make them active. But it > does have the baggage of needing tcl included. About a decade ago, some > people had the idea of removing the tcl dependency, but nothing seems to > have come of that. For some people, the tcl baggage is reason enough to > be rid of tk.
Thanks for raising this point. While I don't want to exhaustively respond to this, I would like to raise a few important points. 1. The performance issues of having Tk use Tcl are negligible; the bulk of Tk (code-wise and time-wise) are spent in C. Tcl itself is also very fast nowadays, using all the usual techniques that modern dynamic languages use. 2. Some people do have moral/purity objections to including Tcl, and while I understand where the sentiment comes from, I think there are few solid engineering reasons for this. 3. Removing Tcl from Tk makes keeping up with changes in Tk very difficult. The Perl people found this out; Perl/Tk extracted Tcl, and as a result remained using a 10 year old version of Tk because upgrading would have been too painful. The newer Perl binding (Tkx) is in fact a ridiculously thin binding over the Tcl API, and makes keeping up to date with the newest Tk changes trivial, often requiring no code changes in the Perl binding. If anyone does have questions, comments or concerns about Python including a Tcl interpreter to use Tk, I'd be happy to try to explain or address them. Mark -- http://mail.python.org/mailman/listinfo/python-list
