[Stackless] PySide problem, take #2: typeobject clash
jpe at wingware.com
Fri Oct 25 20:01:48 CEST 2013
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
>> error: no member named 'as_number' in 'SbkObjectType::<anonymous
>> struct at
>> memset(&Sbk_QBitArray_Type.super.as_number, 0,
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
More information about the Stackless