i'm not sure why this print is needed. the other prints are for a reason (to make time.sleep behave similar to translated wrt. gil). before start_new_thread is called, there is only one thread, so why would any gil issues need to be worked around with a print at that point? also, why does only this start_new_thread need a print but the other very similar calls in pypy/module/thread/test/test_thread.py don't?
are you sure you're not just avoiding some existing problem rather than fixing one?
going around making tests pass by modifying them without understanding why the modification works seems careless. the justification "oh the test passes if i modify it in this way, but i don't really know why it was failing originally or why it works now" doesn't seem right to me. better left failing until understood imo.
The test is one of three that run on windows untranslated in that file. It differs from the others in that it actually tries to start a thread, test_signal and test_exit_twice do not. All the others are skipped under these conditions. The test does not explicitly initialize io (see app_main.set_unbuffered_io or app_main.set_unbuffered_io). This is an issue on windows, where first-time initializing the io during start_new_thread in pypy.module.sys.state.init hangs in _setmode() in streamio._set_fd_binary(). Adding the print initializes the io earlier, then sys.state.init is not doing first-time initialization, preventing the hang.
That is as far as I got in my analysis, which did require some time to do.
I did just now try to add a print to the background thread in the pypy/module/thread/test/test_thread test_start_new_thread, and it caused a hang in exactly the same place ( _setmode ) unless I added a print to the foreground thread as well.
There may be a way to explicitly initialize io, I would be happy to improve the test.