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

[David Abrahams]

Phil Thompson <phil at river-bank.demon.co.uk> writes:

> On Sunday 08 December 2002 2:52 pm, David Abrahams wrote:
>> Hi Phil,
>>
>> 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.
>
> SIP patches PyClass_Type.tp_getattro and PyInstance_Type.tp_getattro.

In that case, the only thing I can imagine is that the attribute
access in question is not actually the one induced by "wc.newCanvas",
but something that happens when "wc.newCanvas()" is invoked. In other
words, something in Paul's WindowController class calls back into
Python. 

Of course, the only way I'd be able to know for sure would be to see
more of the stack trace, and some of the variable values (e.g. the
attribute name) wouldn't hurt... 

>> 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.
>
> SIP generated code is intended to work with any version of Python from 1.5.2 
> onwards.

That's fine; Boost.Python v1 worked with 1.5.2. It isn't that hard to
create your own clones of the builtin 'class' and 'instance'.

>> 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?
>
> It doesn't change the behaviour. The "new" code first calls the old getattro 
> code. If a particular exception has been raised 

Is this a SIP-specific exception or just the usual AttributeError?

> it then searches SIP generated data structures to see if the name
> refers to a SIP wrapped method.  If it does then the appropriate
> Python objects are created and returned in place of the exception.

Aha. Well, as long as "particular exception" is specific to SIP, that
sounds like it is probably harmless... though it makes me uneasy.

> Note that the patching is only done to enhance performance -
> required for PyQt because it has so many classes and methods.

I understand why a performance enhancement might be needed, but it
still seems unlikely to me that patching is actually required.

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