RetroSearch Browse

Wed Sep 24 09:39:48 EDT 2003 · http://mail.python.org/pipermail/python-dev/2003-September/038271.html

On Wed, 2003-09-24 at 07:53, Barry Warsaw wrote:
> On Wed, 2003-09-24 at 03:15, Anthony Baxter wrote:
> > Last chance for feedback on python2.3.1 ... :)
> test test_mimetypes failed -- Traceback (most recent call last):
>   File "/tmp/Python-2.3.1/Lib/test/test_mimetypes.py", line 52, in
> test_guess_all_types
>     eq(all, ['.bat', '.c', '.h', '.ksh', '.pl', '.txt'])
>   File "/tmp/Python-2.3.1/Lib/unittest.py", line 302, in failUnlessEqual
>     raise self.failureException, \
> AssertionError: ['.asc', '.bat', '.c', '.h', '.ksh', '.pl', '.txt'] !=
> ['.bat', '.c', '.h', '.ksh', '.pl', '.txt']
> 

I've seen test_mimetypes fail frequently, depending on what order the
tests are run.  We worked on this a little for 2.3c1, but I didn't have
the patience to stick with it.  The problem is that the mimetypes module
initializes some global variables when it is first used.  test_mimetypes
avoids initializing the module, because it can't guess what extensions
will be known on a particular platform.  But some of the other tests
*use* mimetypes, so they cause it to be initialized.

> In the first run, test_queue also failed, with this output:
> 
> test_queue
> test test_queue failed -- blocking function '<bound method Queue.get of
> <Queue.Queue instance at 0x402471cc>>' appeared not to block

I see this from time-to-time, too.  The tests are timed based and
sometimes fail when there's not enough CPU time during the test
interval.

Jeremy

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2003-September/038271.html below:

[Python-Dev] 2.3.1 is (almost) a go