Re: [Python-Dev] test_descrtut failing
Recently, "Tim Peters" <tim.one@home.com> said:
I'd rather delete the test. But since I doubt Jack is running the test in the devious way shown above, I'll hold off until he surprises me <wink>.
Well, as you've seen from my previous message I'm indeed running the test in this devious way:-) But I must say that I'm mildly surprised that windows users not also do this. In the MacPython installation instructions I suggest people start by firing up the interpreter and doing "importtest.regrtest; test.regrtest.main()". What does PythonWin suggest? That people fire up a dos shell to run the tests? Or does it simply not suggest anything <half-a-wink>? Or do the problems somehow not show up in PythonWin? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
Jack Jansen wrote:
But I must say that I'm mildly surprised that windows users not also do this. In the MacPython installation instructions I suggest people start by firing up the interpreter and doing "importtest.regrtest; test.regrtest.main()". What does PythonWin suggest?
Nothing. It's part of the ActiveState download, not part of Pythonlab's.
That people fire up a dos shell to run the tests?
That's Python on Window's default. But thanks to Tim, it's been tested by the time we get it. or-at-least-floating-point-has-ly y'rs - Gordon
[Jack Jansen]
Well, as you've seen from my previous message I'm indeed running the test in this devious way:-)
Jack, you're still making me guess. Guido's example was
./python >>> import test.test_descrtut # this does not run the tests! >>> test.test_descrtut.test_main() # this does!
and despite your claim above I still don't believe that's what you do. Later in *this* msg you said you suggest that other people do "import test.regrtest; test.regrtest.main()" So which is it? Because the names attached to Python modules depend on exactly how you import the modules, and test_descrtut compares output that includes module names, the precise way in which you run tests is the entire ball of wax here. It appears that test_descrtut is unique among all tests merely in verifying that stuff like >>> print defaultdict # show our type <type 'test_descrtut.defaultdict'> produces the expected output. If we had a straight regrtest that checked test_support.verify(str(defaultdict) == "<type 'test_descrtut.defaultdict'>") it would also fail for you; ditto for a unittest that bothered to check. I get the impression Guido doesn't think this kind of output *should* be verified, though, which is why I'm more inclined to throw the test away than to "fix it" for you.
But I must say that I'm mildly surprised that windows users not also do this.
The plain clumsiness of "import test.regrtest; test.regrtest.main()" should suggest it's not a usual way to run tests.
In the MacPython installation instructions I suggest people start by firing up the interpreter and doing "importtest.regrtest; test.regrtest.main()". What does PythonWin suggest?
PythonWin is the name of Mark Hammond's Windows IDE, so isn't relevant. The test suite cannot be run under IDLE (the Windows IDE we ship with the core), because the threaded tests confuse Tk, causing crashes and hangs; I don't know whether PythonWin has the same problem. I suppose there *may* be a Windows user somewhere who brings up a DOS box, and then starts a Python shell in it, and then does a bunch of obscure imports to run the test suite, but I haven't met one. The natural thing to do on Windows-- and the only thing I ever do --is to run regrtest.py from a DOS command line (and the PCbuild directory has a DOS batch file to partially automate the Windows testing process). But you don't have a command line, so it's not surprising you don't use one <wink>.
That people fire up a dos shell to run the tests? Or does it simply not suggest anything <half-a-wink>?
We don't suggest anything, and I doubt if as many as 1 Windows user in a 1000 ever bothers trying to run the test suite. We ship binaries on Windows, so it's not like Windows users need to test their build process. If I ever ask a Windows user to run a test (maybe once a year?), the natural way to do it remains from the command line, in order to capture the output easily.
participants (3)
-
Gordon McMillan -
Jack Jansen -
Tim Peters