[PySide] [Stackless] PySide problem, take #2: typeobject clash

[John Ehresman]

On 10/22/13 3:42 PM, Christian Tismer wrote:
>> That would really be a minimal patch with much less ugliness and clutter.
>> Well, not sure yet if I want to try that really right now...maybe
>
> Tried this -- does not work.
> While a good idea, the introduced differences are too big to go away with
> this simple trick.
> The thing breaks in for instance
>
>> /Users/tismer/src/pyside-setup/pyside_build/py2.7-qt4.8.5-64bit-release/pyside/PySide/QtCore/PySide/QtCore/qbitarray_wrapper.cpp:1626:38:
>> error: no member named 'as_number' in 'SbkObjectType::<anonymous
>> struct at
>> /Users/tismer/src/pyside-setup/pyside_install/py2.7-qt4.8.5-64bit-release/include/shiboken/basewrapper.h:99:5>'
>>     memset(&Sbk_QBitArray_Type.super.as_number, 0,
>> sizeof(PyNumberMethods));

I looked at this a bit more and it's a bit of a mess (as many things 
with shiboken are so I'm not surprised).  Looking at at, I think there's 
a good possibility the the use of PyHeapTypeObject isn't needed.  The 
as_number initialization above can, I think, be replaced by declaring a 
static PyNumberMethods sruct and then setting the tp_as_number pointer 
to it.  The same can be done for the other tp_as_* pointers.

With this generation change, you shouldn't have any references to 
super.* fields other than super.ht_type.

I also think it's worth trying to fix the binary compatibility problems. 
  If not, we should add something so a library for cpython fails to load 
into a stackless interpreter and vice versa so that things fail early 
rather than in obscure ways later.

But back to my original assumption, does anyone know if 
PyHeapTypeObjects need to be used directly by shiboken (as opposed to 
plain PyTypeObjects)?

Thanks,

John