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

[David Abrahams]

Hi Phil,

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

>    Here is some response I got from the PyQt mailing list.  I joined
> the list in hope to resolve my problems. Note that the author of PyQt
> responsing at 2 am in the morning his time.
>
> ---
>> >>>>> On Sun, 08 Dec 2002 01:29:27 +0000, Phil Thompson
>> >>>>> <phil at river-bank.demon.co.uk> said:
>
>
> SIP takes over the class and instance getattr functions - it patches the class 
> and instance type objects. It does this to implement a "lazy" getattr so that 
> the Python object wrapping a C++ method is only created when that method is 
> referenced. PyQt contains over 5000 methods - if this technique wasn't used 
> then both the startup time of a PyQt application, and the memory it consumed, 
> would make it unusable.

Firstly, Boost.Python doesn't use class and/or instance. It's using
only new-style objects. We have a metatype derived from 'type' and a
type derived from PyBaseObject_Type. But I guess that you must be
patching those base types (or their bases) somehow, because if you
were only patching class and/or instance it should have no effect on
Boost.Python.

If you /are/ in fact patching some of our base types, it seems
unneccessary to me. Situations like this are why Guido created the
new-style type system: you can just use subtypes with overridden
getattr functions. It even seems unneccessary if you're patching class
and instance. The first version of Boost.Python used its own class and
instance types which were clones of the ones built into Python, before
the new-style type system allowed us to eliminate all that code. We
had our ouwn getattr behavior; it worked perfectly.

I don't see how any patch to the Python core which changes its
behavior could avoid breaking other things. Is this really the first
problem it's caused?

>> > The obvious workaround is to re-wrap your widgets using SIP.

No comment ;->

>>    I've already learned on way to expose my C++ to Python, why do I
>> need to learn another way.   SIP should not be doing things to Python
>> that is incompatible with other Python extension modules.   Or is
>> Boost.Python producing something incompatible with other Python
>> extension modules?   Or is there something I'm doing wrong?   This is
>> really hard to decyipher
>
> The real problem is that SWIG/Boost/SIP have to agree on how they are going to 
> represent a pointer to a C++ object - or at least you have to provide code 
> that converts between the different representations.

I don't think that should be neccessary in this case. At first, I too
thought that was Paul's problem.  However, the SIP-wrapped C++ code is
not directly touching the C++ type he's exposing, and the
Boost.Python-wrapped C++ code is not directly touching any types
wrapped by SIP, AFAICT.

> Also, I don't believe (although I'd be happy to be proved wrong)
> that you can produce production quality bindings for Qt derived
> classes using anything other than SIP. For example, how do you
> handle object ownership issues?

Boost.Python has a suite of policies designed for handling object
ownership issues. It may need to be extended to work optimally with Qt
objects, but since Boost.Python is a framework, that should be no
problem.

http://www.boost.org/libs/python/doc/v2/reference.html#models_of_call_policies

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