[Python-Dev] test_quopri, test_wait3, and test_popen2 (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Thu Mar 23 23:40:17 CET 2006
- Previous message: [Python-Dev] Patch to add timestamp() method to datetime objects
- Next message: [Python-Dev] test_quopri, test_wait3, and test_popen2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 <foo.txt" is invoked, the output will contain CRLF even if the input doesn't, this is likely because stdout is in text mode on Windows. Now, subprocess.py is not in text mode (unlike os.popen2), so when reading the results, we see CRLF on Windows, but LF elsewhere.
I fixed this by making the result check line-ending-independent, because I think using CRLF in quoted-unreadable is compliant with the relevant RFC. Alternatively, the quopri.py command line mode could be put into binary mode, so that it produces identical outputs on all systems.
Regards, Martin
- Previous message: [Python-Dev] Patch to add timestamp() method to datetime objects
- Next message: [Python-Dev] test_quopri, test_wait3, and test_popen2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]