[issue17496] OS X test for Tk availability in runtktests.py doesn't work

New submission from Alex Gaynor: If I run: $ python -mtest.test_tk I get a skip, after speaking with people familiar with OS X, it appears that the condition for the skip uses old Carbon APIs, which are totally deprecated under 64-bit. Attached is a patch which should work. -- files:

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Ned Deily added the comment: The test for the condition was added to solve the problem reported in Issue8716. The Tk crash for test_ttk_guionly reported there still occurs on a current 10.8 system with the Apple-supplied Cocoa Tk under the same conditions, that is, when running the tests from

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Glyph Lefkowitz added the comment: Hi Ned, It seems from your comment that you didn't read the patch. Alex added a simpler check via launchctl, rather than by framework symbol groveling :). He didn't remove the check. It should be functionally identical to what's there now, but much shorter

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Ned Deily added the comment: Um, yes, my tired eyes did skip over those added lines. Thanks, Glyph, and sorry, Alex. While the suggested change solves the issue for the non-framework build case, it appears to introduce new problems. For one, with the current skip test, it is possible to run

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Ned Deily added the comment: Granted, the current test is a kludge. We could make it a bigger kludge by trying launchctl first and if it fails move on to the current ctypes-based tests. Any better options? -- ___ Python tracker

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Ronald Oussoren added the comment: A small helper program that does the equavalent of this should also work: import Cocoa Cocoa.NSWindow.alloc().initWithContentRect_styleMask_backing_defer_(((10, 10), (100, 100)), 0, 0, 0) If this code raises an exception you cannot create windows, if it doesn

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Ronald Oussoren added the comment: Wouldn't it be better to check for the actual problem, that is use subprocess to start a small Tcl script that creates a window and check if that crashes? That way the code for disabling the test doesn't have to try to guess whether or not Tk will crash in th

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Glyph Lefkowitz added the comment: > Wouldn't it be better to check for the actual problem, that is use subprocess > to start a small Tcl script that creates a window and check if that crashes? Yes, this sounds great. Doing it with Tcl means that we're not invoking any of the problematic code

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Ronald Oussoren added the comment: The attached patch start wish and stops it by sending the 'exit' command. With the patch I can run the tk tests without getting a skip. I cannot easily test if the patch also does the right thing on buildbots, but have high hopes. I did check that just star

[issue17496] OS X test for Tk availability in runtktests.py doesn't work

Ronald Oussoren added the comment: To respond to my own message: running a small Tcl script is not good enough, the process environment of python itself is also important. In particular, GUI frameworks only work from inside an application bundle (or by using some undocumented private APIs) and