[Python-Dev] FYI: wsgiref is now checked in (original) (raw)
Tim Peters tim.peters at gmail.com
Sat Jun 10 21:22:36 CEST 2006
- Previous message: [Python-Dev] FYI: wsgiref is now checked in
- Next message: [Python-Dev] FYI: wsgiref is now checked in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Just noticed that, at least on Windows, test_wsgiref fails when Python is run with -O (but passes without -O):
$ python -O -E -tt ../Lib/test/regrtest.py -v test_wsgiref test_wsgiref testAbstractMethods (test.test_wsgiref.HandlerTests) ... ok testBasicErrorOutput (test.test_wsgiref.HandlerTests) ... ok testCGIEnviron (test.test_wsgiref.HandlerTests) ... ok testContentLength (test.test_wsgiref.HandlerTests) ... ok testEnviron (test.test_wsgiref.HandlerTests) ... ok testErrorAfterOutput (test.test_wsgiref.HandlerTests) ... ok testHeaderFormats (test.test_wsgiref.HandlerTests) ... ok testScheme (test.test_wsgiref.HandlerTests) ... ok testExtras (test.test_wsgiref.HeaderTests) ... ok testMappingInterface (test.test_wsgiref.HeaderTests) ... ok testRequireList (test.test_wsgiref.HeaderTests) ... ok test_plain_hello (test.test_wsgiref.IntegrationTests) ... ok test_simple_validation_error (test.test_wsgiref.IntegrationTests) ... FAIL test_validated_hello (test.test_wsgiref.IntegrationTests) ... ok testAppURIs (test.test_wsgiref.UtilityTests) ... ok testCrossDefaults (test.test_wsgiref.UtilityTests) ... ok testDefaults (test.test_wsgiref.UtilityTests) ... ok testFileWrapper (test.test_wsgiref.UtilityTests) ... FAIL testGuessScheme (test.test_wsgiref.UtilityTests) ... ok testHopByHop (test.test_wsgiref.UtilityTests) ... ok testNormalizedShifts (test.test_wsgiref.UtilityTests) ... ok testReqURIs (test.test_wsgiref.UtilityTests) ... ok testSimpleShifts (test.test_wsgiref.UtilityTests) ... ok
====================================================================== FAIL: test_simple_validation_error (test.test_wsgiref.IntegrationTests)
Traceback (most recent call last): File "C:\Code\python\lib\test\test_wsgiref.py", line 156, in test_simple_validation_error "AssertionError: Headers (('Content-Type', 'text/plain')) must" AssertionError: 'ValueError: too many values to unpack' != "AssertionError: Headers (('Content-Type', 'text/plain')) mus t be of type list: <type 'tuple'>"
====================================================================== FAIL: testFileWrapper (test.test_wsgiref.UtilityTests)
Traceback (most recent call last): File "C:\Code\python\lib\test\test_wsgiref.py", line 312, in testFileWrapper self.checkFW("xyz"*50, 120, ["xyz"*40,"xyz"*10]) File "C:\Code\python\lib\test\test_wsgiref.py", line 211, in checkFW compare_generic_iter(make_it,match) File "C:\Code\python\lib\test\test_wsgiref.py", line 100, in compare_generic_iter raise AssertionError("Too many items from getitem",it) AssertionError: ('Too many items from getitem', <wsgiref.util.FileWrapper instance at 0x00B432D8>)
Ran 23 tests in 0.046s
FAILED (failures=2) test test_wsgiref failed -- errors occurred; run in verbose mode for details 1 test failed: test_wsgiref
This may be because compare_generic_iter() uses assert
statements,
and those vanish under -O. If so, a test shouldn't normally use
assert
. On rare occasions it's appropriate, like test_struct's:
if x < 0:
expected += 1L << self.bitsize
assert expected > 0
That isn't testing any of struct's functionality, it's documenting and verifying a fundamental belief of the test author's: the test itself is buggy if that assert ever triggers. Or, IOW, it's being used for what an assert statement should be used for :-)
- Previous message: [Python-Dev] FYI: wsgiref is now checked in
- Next message: [Python-Dev] FYI: wsgiref is now checked in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]