I have been looking into the (seemingly random) test_popen2
failures today, and found that it fails when the tests
are run in the order given in the subject.
Here is what happens:
- test_quopri uses os.popen2, which in turn creates a popen2.Popen3
object. It processes stdin/stdout, but never calls wait on that
the process (it can't: os.popen2 doesn't return the pid).
This is a flaw (the process should be waited for) which I fixed.
- test_wait3 has a loop to wait for child processes, which invokes
wait repeatedly until the expected child pid is returned. In
the process, it might receive the wait status from processes it
didn't start. This is a flaw which I didn't address - I wonder
why there is a loop, instead of just waiting once, and expecting
the PID of the process that had been created just before.
- test_popen2 invokes _cleanup at the end, which waits for all
_active processes. Now, since test_quopri added an active process,
and test_wait3 deleted its pid, _cleanup fails with the error that
the pid is no longer valid.
I made that failure more obvious.
So here is what I did to address these:
- I changed test_quopri to use subprocess.Popen().communicate()
to invoke quopri as a program. communicate will wait() for the
child process.
- I changed test_popen2 to check at the beginning that there are
no active processes. To print out the commands that are still
active, I added the cmd string to the Popen objects.
It turned out that this broke the Windows builds, which, in turn,
resolves as a hidden bug/feature of quopri command line mode.
When "python -mquopri