[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