[Adonthell-devel] Python weirdness (a real weirdy one) - please test

[Alexandre Courbot]

Today I wanted to port my intersection tests to 0.4. I had some weird python 
errors, so I've tried on another simpler example (it's test/gfxtest.py).

The main loop code contains the following lines:

        input.manager.update()
        ssurface.fillrect(10, 10, 50, 50, 0xffffff)

Nothing bad here, and the code runs. It runs until I press a key, which cause 
the callback function to get called. It runs and return, and they Python 
exits with the following error: 

Traceback (most recent call last):
  File "gfxtest.py", line 27, in ?
    ssurface.fillrect(10, 10, 50, 50, 0xffffff)
  File "/home/alex/Work/Adonthell/adonthell/src/py-wrappers/adonthell/gfx.py", 
line 111, in fillrect
    res = apply(_gfx.surface_fillrect,args)
TypeError: an integer is required

It returns some type error from the fillrect call right after. Now if I move 
the input.manager.update() line at the top of the block, it works without any 
problem.

I've investigated it a bit more and checked the wrappers generated by SWIG. It 
contains the following code:

    if(!PyArg_ParseTuple(args,(char 
*)"OhhOOO|O:surface_fillrect",&obj0,&arg2,&arg3,&obj3,&obj4,&obj5,&obj6)) 
goto fail;
    if ((SWIG_ConvertPtr(obj0,(void **) &arg1, 
SWIGTYPE_p_gfx__surface,SWIG_POINTER_EXCEPTION | 0 )) == -1) SWIG_fail;
    arg4 = (unsigned short) PyInt_AsLong(obj3);
    if (PyErr_Occurred()) SWIG_fail;
    arg5 = (unsigned short) PyInt_AsLong(obj4);
    if (PyErr_Occurred()) SWIG_fail;
    arg6 = (unsigned int) PyInt_AsLong(obj5);
    if (PyErr_Occurred()) SWIG_fail;

It's the line "arg4 = (unsigned short) PyInt_AsLong(obj3);" which fails, 
setting the error flag (PyErr_Occurred is not None) after that. But! obj3 IS 
an integer! I can print it using PyObject_Print, it prints the right value. 
And PyInt_Check returns true! And after the call to PyObject_Print the value 
in arg4 is the right one.

So, basically, it looks like the Python error flag is erroneously set when we 
try to convert an integer right after calling a callback function while 
everything is actually correct... Geeee. I don't know what to think from this 
one, excepted, maybe (hopefully) it's a Python bug? I'm using Python 2.2.2 
here, can you guys test with your version of Python? It's just updating the 
CVS, compiling it again, run gfxtest.py and press a key. I'll see what to do 
(fill a bugreport to the Python guys or hang myself) from your reports.

Thanks!
Alex.
-- 
http://www.gnurou.org