[Guido, on finding Tcl/Tk under Windows] > 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. Unless you're Fredrik, alas <wink>. Apparently Tcl still honors library envars first if they exist, and if some other installation or use of Tcl/Tk set those, you can still end up w/ a mix. *Much* better than before, though, and I don't recall ay instance of this happening in real life so far apart from /F (who had no problem figuring it out, of course). >> 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) I'll second that! "Mystery startup errors" from the Python+Tcl+Tk+Windows combo were at least weekly questions on c.l.py for 1.5.2, often daily. I've seen none for 1.6 or 2.0. and-all-it-took-was-avoiding-ms's-recommended-practices<wink>-ly y'rs - tim
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