[issue17883] Fix buildbot testing of Tkinter

[Terry J. Reedy]

Terry J. Reedy added the comment:

I wonder if there is something special about the environment on that Snakebite machine. At the top, it says 
 PATH=C:\Perl\site\bin;C:\Perl\bin;E:\apps\activestate-python-2.7.2.5-x86\;E:\apps\activestate-python-2.7.2.5-x86\Scripts;...
Could the presence of activestate-python affect the build?

Ignoring the 'no buffer in 3.0' warnings, there are a couple of warnings that suggest updates to test_tcl.py. Another issue though.

The context for the failure is
        with test_support.EnvironmentVarGuard() as env:
            env.unset("TCL_LIBRARY")
            f = os.popen('%s -c "import Tkinter; print Tkinter"' % (unc_name,))
        self.assertTrue('Tkinter.py' in f.read())

I do not know why test_tcl is testing the ability of python to be opened from a unc path (I am not familiar with them), but anyway...

The assertion is testing the read of the printed Tkinter module representation. On my 2.7.4 install, the result is "<module 'Tkinter' from 'C:\Programs\Python27\lib\lib-tk\Tkinter.pyc'>". On my machine, the test reads that and passes. (On 3.x, the test is ('tkinter' in f.read()) as the file is tkinter/__init__.py instead of Tkinter.py.)

To see what is going on with the failing machine, an update to
        self.assertIn('Tkinter.py', f.read())
will show the f.read() that does not contain 'Tkinter.py'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17883>
_______________________________________