On 1/5/2011 8:59 PM, Nick Coghlan wrote: > On Thu, Jan 6, 2011 at 9:47 AM, Terry Reedy<tjreedy at udel.edu> wrote: >> To test Brett's test running instruction, I ran >> python -m test # not ./Python! >> in a Command Prompt window > > Does it behave itself if you add "-x test_capi" to the command line? No, it gets worse. Really. Let me summarize a long post. Run 1: normal (as above) Process stops at capi test with Windows error message. Close command prompt window with [x] buttom (crtl-whatever had no effect). Run 2: normal (as before) Process reported capi test failure (supposedly fatal) but continued. Process just stopped ('hung') at concurrent futures. Close as before. Run 3: -x test_capi test_concurrent_futures Instead of the normal output I expected, I got some of the craziest stuff I have ever seen. Things like " assert main_name not in sys.modules, main_name AssertionError: __main__ Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 369, in main prepare(preparation_data) File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 477, " were printed 100s of times intermixed with the normal sequential test startup lines. They stopped after text_sax started and output became normal through the end of the report. 295 tests OK. 11 tests failed: test_datetime test_difflib.bak test_ftplib test_lib2to3 test_multiprocessing test_os.bak test_pep277 test_pkgutil test_posixpath test_runpy test_tcl 2 tests altered the execution environment: test___all__ test_site 41 tests skipped: [snip] 4 skips unexpected on win32: test_gdb test_readline test_tk test_ttk_guionly (It previously said it could not find tk (or ttk), even though IDLE does just fine.) Then chained error craziness during shutdown: SystemExit, WindowsError, AttributeError, EOFError (details in original post). I forgot to mention before that test_ftplib runs into Windows security and pops up a window (which I closed). If I did not know better, I might have thought python to be a buggy piece of junk, but my well-tested package-in-progress runs fine (from IDLE edit window) in 3.2b2, unchanged from 3.1. I think fixing test regressions should happen before a 'release candidate'. On same machine (again, installed from Martin's .msi) C:\Programs\Python31>python -m test.regrtest seems to run 'normally' (same security popup), no craziness (except for blocked ftplib test), with results 298 tests OK. 3 tests failed: test_ftplib test_lib2to3 test_tcl 39 tests skipped: [snip] 2 skips unexpected on win32: test_tk test_ttk_guionly test_tcl had multiple errors, tk,ttk skips are from not finding usable init.tcl Similar result with 2.7 with addition of test_distutils failure and 'unexpected skips' of test_gbd and test_readline (but I presume these really should be expected). -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4