>>> 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. [Barry Warsaw] > 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? googling on test_guess_all_types nails it: http://mail.python.org/pipermail/python-dev/2003-September/038264.html Jeff Epler reported there, in a reply to you about the same thing in 2.3.1, that test_urllib2 interferes with test_mimetypes (when run in that order), and included a patch claimed to fix it. Of course, since he didn't put the patch on SF, it just got lost.
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