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

[Phil Thompson]

On Sunday 08 December 2002 2:52 pm, David Abrahams wrote:
> 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.

I'd just finished the washing up after a dinner party.

> >> >>>>> 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.

SIP patches PyClass_Type.tp_getattro and PyInstance_Type.tp_getattro.

> 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.

> 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 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.

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

Phil