If the DISPLAY environment variable is set, the test_tcl test
'testLoadTk' gives a traceback.  In the same circumstance, test_tk and
test_ttkguionly display the error and are skipped.  Although this is a
nit rather than a problem, for consistencies sake I think the testLoadTk
test should also be skipped rather than show up as a failure.  I've
attached a patch against the trunk that does this, with the caveat that
it is an individual testcase being skipped so it doesn't get recorded in
the 'skipped tests' summary.  I don't think this is a problem since
test_tk will likely show up in the skipped tests if this one is skipped,
and also there are circumstances in which testLoadTkFailure is skipped
completely silently.

Perhaps the real problem is that the tk tests should be in test_tk
instead of test_tcl?

That first sentence should have read "If the DISPLAY environment
variable is set but the display cannot be opened".

Patch uploaded as bzr branch to Launchpad at

  bzr+ssh://bazaar.launchpad.net/~rdmurray/python/bug5450-test

Please use test_support.TestSkipped instead of showing a skip message
using print.

It should be okay to move tk tests to somewhere in
Lib/lib-tk/test/test_tkinter/ (answering the final question). Even the
rest of test_tcl could be relocated to that place.

I tried using TestSkipped first, but since I was throwing it from an
individual testcase and not from the top level, it still showed up as an
error in test_tcl (I may have done it wrong, of course).

Moving the tests makes more sense anyway, so I've revised my patch to do
that.  I didn't move all of the tests because as far as I could
understand the test.test_tk code, if I moved them all they'd only get
run if the GUI resource was enabled, and that seems wrong.  So I just
moved the tests that specifically involved tk.

I ran the test suite under a variety of DISPLAY settings and
non-settings, and it seemed to do the right thing with the patch
applied.  I have pushed the change up to Launchpad as well.

Oops, I forgot to remove the changes I'd previously made to testLoadTk.
I've updated the patch file and pushed to Launchpad, after re-running my
tests.

Uhm, I don't agree with this TkinterTest name since it is only doing a
minor test on _tkinter._flatten. This same class is indicated in
tests_gui but it doesn't require gui to run, it should be indicated only
in tests_nogui.

Then there is TclTest which I also don't agree with the name, it is only
testing tk loading so a different name would be better here.

And finally the file is named test_tcl.py which to me suggests something
that won't require gui, but that is exactly what it does by doing
test_support.requires('gui').

Any chance you can improve these names ?

On Tue, 24 Mar 2009 at 18:24, Guilherme Polo wrote:
> Any chance you can improve these names ?

Absolutely.  I agree with you; I was trying to stay parallel to the
original names, but it felt wrong.  And since I don't know TCL/TK/tkinter,
I didn't know what flatten was testing.  I'll make it non-gui.

Finally I'm looking into this again. So, for now, I decided to only move
the tk load tests to Lib/lib-tk/test/test_tkinter under a new module
named test_loadtk. Lib/test/test_tcl remains almost the same, except it
no longer it contain those tests related to tk loading.

Patch attached. May I reassign it to me David ?

On Sun, 21 Jun 2009 at 14:57, Guilherme Polo wrote:
> Patch attached. May I reassign it to me David ?

Absolutely.

Running tk tests through both Lib/test/test_tk.py and
Lib/test/regrtest.py show the desired behaviour (from what I understood
from your description and from what I tested).

It has been committed now, r73495 (trunk).

Should 2.6 and 3.0 really receive this patch ? I've removed them from
the list in this issue, please add back if it is really needed.

No, I don't see any reason to bother backporting.  From my understanding
we're not backporting anything to 3.0 at this point anyway.

Fine, closing then.

Committed as r73497 on py3k.