Turns out the mysterious "expected output" file contained exactly N dots,
because test_poll() has a loop that *usually* went around N times,
printing one dot on each loop trip. But there's no guarantee of that,
because the exact value of N depended on the vagaries of scheduling
time.sleep()s across two different processes. So stopped printing dots,
and got rid of the expected output file. Add a loop counter instead,
and verify that the loop goes around at least a couple of times. Also
cut the minimum time needed for this test from 4 seconds to 1.
tester that a DOS box is expected to flash. Slash the sleep from 2
seconds to a quarter second (why would we want to wait 2 seconds just
to stare at a DOS box?).
what this is trying to do. If it's necessary for it to create > 1000
processes, it should be controlled by a new resource and not run by
default on Windows.
display a test's docstring as "the name" of the test. So changed most
test docstrings to comments, and removed the clearly useless ones. Now
unittest reports the actual names of the test methods.
Bug fixes:
* Use fresh copy of globals/locals so the script being debugged can't access
the pdb namespace (e.g.: p line_prefix will no longer work).
* Remove pdb.py's path from sys.path. Having it in there is normally not a
problem, but it could prove irritating when messing with PYTHONPATH or
invoking pdb via /usr/bin/pdf.
* You can now set a breakpoint on the script being debugged, even if the script
doesn't end with a '.py' extension. Also, setting breakpoints with absolute
paths now works reliably.
Enhancements:
* Go directly to the first line of the script.
* Enter post-mortem debugging if the script being debugged doesn't catch an
exception.
* Restart the script being debugged and preserve debugger state when the script
being debugged exits.
Cleanup:
* Moved the __main__ method into a main() function.
* Kill the (undocumented, not in __all__) mainmodule/mainpyfile globals, add a
mainpyfile attribute to pdb.
Thanks Ilya Sandler for the patch!
popen2.popen2/3/4 functions can be a sequence. All texts are a variation on the
following:
On \UNIX, \var{cmd} may be a sequence, in which case arguments will be passed
directly to the program without shell intervention (as with
\function{os.spawnv()}). If \var{cmd} is a string it will be passed to the shell
(as with \function{os.system()}).
thread's id can't get duplicated, because (of course!) the current thread
is still running. The code should work either way, but reverting the
gratuitous change should make backporting easier, and gets the bad
reasoning out of 2.35's new comments.
