Message4705

Turns out this is just an abuse of subprocess.call. The code is 
originally from test_cmd_line, doh

call just wait()s, it doesn't consume the PIPEs we specify. With nothing 
consuming those pipes, the child can deadlock after writing enough 
output to fill the pipe's buffer

The -m runpy fnordXXX was the only trigger because it wrote enough 
output (a traceback) to fill the buffer, and it only happened on Windows 
because Windows has a pretty small pipe buf

The author of subprocess confirms that this is indeed a bad idea here:
http://mail.python.org/pipermail/python-dev/2006-June/066111.html

fixed in r6363