> Andrew Kuchling wrote: > > > Can someone articulate why Tk should be replaced? Jim Ahlstrom replied: > I don't know whether Tk should replaced, but I > can explain why I don't use it for our commercial > Python application. > > It is just too big and complicated. Windows comes > with a built-in GUI, and I hesitate to install > another scripting language (Tcl) and its libraries, > and then install a big system which has frequently been > out of phase with Python releases just to access the > Windows GUI. To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer. That's different -- and better -- than what happened in 1.5.2, where a separate Tcl/Tk installer was optionally run. The version issues are also resolved this way: you are guaranteed to get exactly the Tcl/Tk version that was tested by the developers. > What if a user calls with a problem? Why should I > have to debug their Tcl library path problems? No > thanks. The Tcl library paths are all taken care of by the new installer strategy. Really, give it a try. It Just Works! (SM) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4