[New-bugs-announce] [issue18604] Consolidate gui available checks in test.support

Terry J. Reedy report at bugs.python.org
Wed Jul 31 02:13:35 CEST 2013


New submission from Terry J. Reedy:

Current situation:

test.support.requires starts with
     if resource == 'gui' and not _is_gui_available():

On windows, _is_gui_available() uses ctypes to determine that there really is a graphics screen. On other systems, it just returns True, even when it should return False. The _is_gui_available check is repeated with each requires('gui') call even though all after the first would be redundant if False were somehow recorded. I think it should be. 

test/test_ttkguionly first tries to import _tkinter, as does test_idle, which initializes tcl/tk. It then calls tkinter.test.support.check_tk_availability. That either does a 'darwin'-ctypes check similar to the one for Windows in _is_gui_available (again to avoid a crash), or it tries to create a tk widget and looks for a TclError. Given that tcl has already been initialized successfully, the widget creation check is a gui-available check for non-Darwin systems. A global in tkinter.test.support records the result of the check so it is only run once.

If 'gui' is in use_resources, test_idle just does the widget check for *nix gui availability. It records a negative result by removing 'gui' from use_resources.

The tkinter system does not work for Idle because Idle tests use unittest test discovery instead of tkinter's custom test discovery. Given that, splitting test_idle into test_idle_text and test_idle_gui seems to not be possible. Anyway, if test_idle were to be split, categories like '_windows', '_dialogs', and '_extensions' would be much more sensible and useful.

----------------
For this issue, I propose:

1. Move the custom darwin gui check to test.support, after the custom windows gui check. It should be noted that a) Both of these are gui-framework independent; and b) Neither seems to be needed for any current buildbots (which makes it hard to verify that they work on current systems). However, they were needed in the past and might be again in the future, so each should be checked *once* in each regrtest run with 'gui' set.

2. If the crash-avoidance checks pass, run tkinter.Tk() as a final check on all systems (but especially those not covered by the first checks). But note in comments that this will have to change if tk is augmented or optionally replaced by another gui framework.

3. In requires(), run the above if 'gui' is set and requested, and record a negative result by unsetting 'gui' (removing it from use_resources). Perhaps output a note that this has been done. Subsequent gui requests will skip. I considered putting this logic in regrtest instead, but see 4.

4. Currently, requires never skips when the caller is the main module. Perhaps requires('gui') should skip even then when there is no gui system. This could happen if a no-gui system ran a console script with "python -m test.text_xxx".

5. Remove the current gui check from test_idle. Idle tests should continue to work as they are.

6. Revising test_tk and test_ttk_guionly to use the revised test.support would be a larger patch. It might best be done while modernizing the tkinter test system to use unittest discovery and .main, in another issue. I am still learning the details of the tkinter test system.

-----
To avoid immediate controversy, I marked this as an 'enhancement' for 3.4. But if the Mac 'darwin' check were currently needed, I would consider it a bug that it is buried in a tkinter function whose API is not right for Idle, instead of being in test.support. (And in 2.7, the function is buried in a module in a package with an illegal name.) So I think backporting should be considered.

----------
messages: 193966
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Consolidate gui available checks in test.support
type: enhancement
versions: Python 3.4

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


More information about the New-bugs-announce mailing list