Heads up. Recent changes to optparse and/or to its test are causing several spurious test failures, Here's a minimal incantation to get the first new failure of this kind: C:\Code\python\PCbuild>python -E -tt ../lib/test/regrtest.py test_optparse test_pep277 test_optparse test_pep277 test test_pep277 produced unexpected output: ********************************************************************** *** lines 2-4 of actual output doesn't appear in expected output after line 1: + u'\xdf-\u66e8\u66e9\u66eb' + ['???', '???', '??????', '????????????', '????G\xdf', 'Ge??-sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] + [u'Gr\xfc\xdf-Gott', u'abc', u'ascii', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u043 2\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u 05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] ********************************************************************** 1 test OK. 1 test failed: test_pep277 In all, with a complete test run, there are 15 spurious test failures on Windows now: 15 tests failed: test_pep277 test_pkg test_popen test_popen2 test_profile test_pyexpat test_regex test_rgbimg test_rotor test_scope test_thread test_threadedtempfile test_tokenize test_winreg test_xreadline No idea why. Offhand, from the symptoms it looks like a change may be sending stdout into a black hole. Constructs like sys.stdout = StringIO() ! self.assertRaises(self.parser.parse_args, (cmdline_args,), None, ! SystemExit, expected_output, ! self.redirected_stdout) sys.stdout = sys.__stdout__ in the patch certainly intensify that suspicion <wink>.
[Tim]
Heads up. Recent changes to optparse and/or to its test are causing several spurious test failures, ...
OK, this is definitely the fault of the recent optparse checkins. For whatever reason, after test_optparse runs, regrtest.py is convinced that the test directory is '/foo/bar'. After that, it can't (among other things) find the expected-output files anymore for tests that run after test_optparse. I'm sure I'll have that fixed soon. But I want to whine about this one more time: PLEASE don't check things in without running the whole test suite! Each weekend now I'm struggling like hell to give some time to Python, and I largely piss it away fixing new test breakage in tests that must have failed on the platform where the patch was developed. I have all the sympathy in the world for Windows-specific test breakage due to patches developed on Linux, but I'm out of sympathy for plain sloppiness. So there.
Tim Peters wrote:
PLEASE don't check things in without running the whole test suite!
I for one would rather that you didn't waste your time on something that somebody else could have and should have done instead. Why not adhere to the Checkin Policy? * Before checking in a code change, re-run the entire Python test suite to be sure that you haven't broken anything. -- http://www.python.org/dev/tools.html Especially in a clear-cut case like this, just revert the changes and send the ball back to the offender's court. -- David Goodger http://python.net/~goodger
participants (2)
-
David Goodger
-
Tim Peters