On Sat, 2003-11-22 at 07:59, Barry Warsaw wrote: > On Sat, 2003-11-22 at 00:10, Jeremy Hylton wrote: > > > > Did a cvs update about 30 minutes ago. make test reports no errors. > > > Running again with "-u all -r" to see what happens. > > > > Also looks good. This was with a RH9 system. > > Unfortunately, no so for me: > > test_mimetypes > test test_mimetypes failed -- Traceback (most recent call last): > File "/home/barry/projects/python23/Lib/test/test_mimetypes.py", line 52, in test_guess_all_types > eq(all, ['.bat', '.c', '.h', '.ksh', '.pl', '.txt']) > File "/home/barry/projects/python23/Lib/unittest.py", line 302, in failUnlessEqual > raise self.failureException, \ > AssertionError: ['.asc', '.bat', '.c', '.h', '.ksh', '.pl', '.txt'] != ['.bat', '.c', '.h', '.ksh', '.pl', '.txt'] > > But we've seen these before, right? Doesn't some test interfere with > globals in a way that screws mimetypes occasionally? Yes and yes. Use of mimetypes causes the module's init() function to be run on a set of known files. test_mimetypes calls init() after zapping the list of knownfiles. init() does not clear out existing global state before re-initializing, which is why the test fails if mimetypes has been used before test_mimetypes. Jeremy
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