[C++-sig] Can boost.python and PyQt be used together?

[David Abrahams]

"Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:

>>>>>> On Sat, 07 Dec 2002 15:02:53 -0500, David Abrahams <dave at boost-consulting.com> said:
>
>> "Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:
>>> I have some widgets which inherit from Qt and made them as Python
>>> extension module using boost.python (v2).
>
>> So, in Python they're represented as Boost.Python extension
>> instances containing instances of your widget classes (?)
>
>   Yes.  My C++ objects are wrap by Boost.Python
>
>>> Now another group wants to use them in their application built with
>>> PyQt which uses SIP to make the Python extension modules.  At first
>>> glance, it looks like this wouldn't work.
>
>> If I understand you correctly, whether it would work or not depends
>> on how sophisticated SIP can be about unwrapping a Boost.Python
>> extension instance and retrieving the underlying C++ object. I doubt
>> SIP has this ability built-in, but it may be possible for you to add
>> it.
>
>    I don't see why SIP needs to know my objects are wrapped by
> Boost.Python.   But let me show you some Python code
>
> a = QApplication(sys.argv) 
> clock = DigitalClock()
> clock.resize(170,80)
> a.setMainWidget(clock)
> clock.show()
> # the above are Python objects wrapped with SIP
> # below are my objects wrapped with Boost.Pythoin
> wc = WindowController()
> cw = wc.newCanvas()
>
> a.exec_loop()

Oh, I see that there's no interaction on the C++ side. 

In that case, I agree with you. There's no reason Boost.Python and SIP
should have to interact in any way.

>
>> 1. Get Boost.Python to wrap your objects in a way that SIP already
>> undertstands
>
>> 2. Get SIP to understand the way Boost.Python already wraps objects
>
>    Why should SIP need to know about my objects or vica versa?

I assumed that because you cited a problem, there must be one, and the
only kind of issue I can imagine arises when the C++ code wrapped with
SIP needs to use a type which you've wrapped with Boost.Python, or
vice-versa.

> I've trace the point of a problem a bit further.   Steping down the
> call stack, I see...
>
> #6  0x0807705e in eval_frame (f=0x811a974) at Python/ceval.c:1784
> (gdb) 
> #5  0x08056794 in PyObject_GetAttr (v=0x82cc4cc, name=0x815a8e0)
>     at Objects/object.c:1108
> (gdb) 
> #4  0x401afa43 in instanceGetAttr ()
>    from /usr/local/lib/python2.2/site-packages/libsip.so
>
> Note the function is in libsip.so.   The line in PyObject_GetAttr()
> that got us there appears to be...
>
> 	if (tp->tp_getattro != NULL)
> 		return (*tp->tp_getattro)(v, name);
>
> Perhaps SIP depends on overriding something in Python in order to
> interact with it's extension modules.

I don't know, but this certainly appears to be a SIP problem. I don't
think this has anything to do with Boost.Python.

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution