Re: [pygame] intermittant fails of unit test pixelarray_test.PixelArrayTest with Python 2.4

[mva@xxxxxxxxxxxx]

Lenard Lindstrom <len-l@xxxxxxxxx>:

> I was trying out one of my custom Windows builds of Pygame 1.8.0rc3 rev
> 1126 with Python 2.4. Using run_tests.py to check the Python 2.4
> version before release I found the following fail:
>
> ................................................................................
> ........F.........................
> ======================================================================
> FAIL: test_contains (pixelarray_test.PixelArrayTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "test\pixelarray_test.py", line 149, in test_contains
>    self.assertFalse (0x0000ff in ar)
> AssertionError
>
> ----------------------------------------------------------------------
>
> I traced it to the case where bpp is 8. However, it is not consistent.
> This error does not show up with my Python 2.5 build of Pygame. The
> error may involve some subtle interaction between the two Python
> versions, possibly involving .pyc files. I installed Brian Fisher's
> build of 1126 and it only failed on the second try out of approximately
> ten trials. When I ran the unit tests on Python 2.4 and Python 2.5 in
> two separate Pygame source directories Python 2.4 finally passed the
> tests consistently.
>
> I just bring this up since it shows possible problems with testing more
> than one version of Python on the same system. If it is a Pygame bug it
> is unpredictable and hard to pin down. So please keep a watch for
> similar problems. Maybe someone using Python 2.4 and SVN version 1126
> of Pygame can run the unit tests ten or more times consecutively to
> check if it passes consistently? My installers are available at
> http://www3.telus.net/len_l/pygame.htm along with SVN version 1126 of
> the Pygame 1.8 documents and examples in compressed and installer form.

Interesting issue. Do you use x64 hardware to test? Maybe it's related by
the Py_ssize_t changes we made for backwards compatibility.
I'll recheck that for my systems and try to find out, what's going on.

Regards
Marcus