[Stackless] http://www.stackless.com/pipermail/stackless/2007-April/000142.html

Kristján Valur Jónsson kristjan at ccpgames.com
Thu Apr 12 12:24:10 CEST 2012

Yes, but all the extra Stackless data are always _at the end_ of the object, and are only present if the Py_TPFLAGS_HAVE_STACKLESS_EXTENSION flag is present in the type.
Stackless itself always checks for this flag's presence in the types it works with, in case they come from external modules.

So, as I see it there are two cases:
a) The PySIDE wrappers generate their own PyHeapTypeObjects.  If they are defined with STACKLESS, they will have included the stackless headers, will have the extra stackless parts in them, and they will be initialized to zero.  The above mentioned flag will also be present in the type.  All should work.
b) the same, but compiled against regular python.  The flag is missing from the type info.  The type layout is the same, though, right up to the python extensions.  Stackless will see the flag missing from its definition and know that there is no python extension....

Aha, maybe the issue is with b, because currently stackless may be assuming that all PyHeapTypeObjects have the stackless extension, even though they don't have the flag.
Fixing this may be sufficient, then.  Let me go in and have a look at the problem.


> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Richard Tew
> Sent: 12. apríl 2012 03:07
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] http://www.stackless.com/pipermail/stackless/2007-
> April/000142.html
> On Sat, Apr 7, 2012 at 6:35 AM, Kristján Valur Jónsson
> <kristjan at ccpgames.com> wrote:
> > Here is a proposed diff file.
> > Note that this change doesn't actually change the object layout, it merely
> changes the header definition of PyHeapTypeObject.
> > Thinking about the problem, I don't see that there is a binary
> incompatibility between stackless and objects built against vanilla
> python27.  The extra "slpflags" is always at the end, and in the case of
> PyTypeObject padded so far that tthis type has the same size as
> PyHeapTypeObject.  It is only present if the "stackless" flag is present in the
> type.
> > So, I think that PyQT and PySide, if compiled against vanilla python, would
> work against stackelss.  This proposed change makes the convenient change
> that these extensions can be compiled against stackless headers as well, if
> need be.
> I've dug out the email I sent to Christian from when I looked into this.  I
> expect the problem described below is still as relevant with your patch, as it
> is without it.  That is, the extended Stackless PyHeapTypeObject can never
> be compatible with any SIP-based code that has been compiled against
> vanilla Python.
> Of course, correct me if I am wrong :-)
> Cheers,
> Richard.
> -- >8 --
> Have you seen the threads on the Stackless mailing list dealing with the
> problems relating to PyQT and the sip package used for bindings for QT to
> Python?
> A quick recap in case you haven't.  Stackless makes PyHeapTypeObject a
> define for PyTypeObject.  sip has PyHeapTypeObject as a member of its own
> structure and initialises it with the expectation that three levels of
> initialisation are required.
> ... {
>  {
>   {
>      /* PyTypeObject initialisation level */
>   },
>   /* PyHeapTypeObject initialisation level */  },
>  /* custom initialisation level */
> }
> Now Visual Studio will give an initialisation error.  But gcc will compile it and
> not initialise anything, which leads to submarine errors that pop up on them
> like the people using PyQT and sip are experiencing.
> -- 8< --
> Correct me if I am wrong, but your patch is going to have the same problem.
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless

More information about the Stackless mailing list