[PyKDE] Help with SIP

[Phil Thompson]

On Thursday 23 December 2004 8:52 pm, Claus, Richard wrote:
> The C++ part of my module is a collection of iterators over, and accessors
> to a buffer of data.  It doesn't depend on any other packages (e.g. Qt). 
> SIP is used to provide an interface to this package from Python.  In some
> Python environments, the result is a single threaded program, not using Qt,
> PyQt, etc.  In other environments, my package is used in the presence of
> Qt, PyQt, and various other packages.  In order to keep Qt GUI screen
> updates crisp, we've seperated that application into multiple Python
> threads.  The one Qthread we have is used for communicating GUI requests
> from a Python thread to the GUI thread.  My module is run purely from one
> of the Python threads.
>
> There is some small amount of handwritten SIP code, yes, although it was
> signficantly reduced in the move from SIP 3 to 4.
>
> No, there are no threads or other system calls in the package itself. 
> However, users may resolve some of the module's virtual methods with Python
> code that does use system calls or functions that affect the GIL.  Prints
> in the SIP generated cpp and a test virtual method don't appear in the non
> -g case, so it's not getting far enough to exercise problems caused by such
> user code.

A word of warning on the -g flag.  It was implemented as an emergency fallback 
in case the new GIL handling proved problematic - which it hasn't. I've never 
used it in anger and can't really vouch for it - in fact I think I'll 
deprecate it.

> BTW, I forgot to ask how to use SIP's debug printing option (-r).  Naively
> turning it on doesn't show anything on stdout.  Is there a run-time flag
> that must be enabled?  I don't see it described in the SIP documentation.

See sip.settracemask() in the section "Using the SIP Module in Applications".

> One fly in the ointment that may affect this discussion is that the C++
> class in which the problem occurs is derived from an abstract base class. 
> The derived class provides implementations for the base class's pure
> virtual methods, in addition to other functionality.  Both the derived
> class and the base class are exposed to Python with SIP since in some
> applications one wants the one and in others the other.  The derived class
> and the base class have their own SIP files which don't contain any
> handwritten SIP code.  Oddly, I found that I had to declare the pure
> virtual methods of the base class that were resolved by the C++ derived
> class, and thus no longer needing exposure to Python, in the SIP code or
> they wouldn't be called.  When SIPed without -g, I see that a print in one
> of these C++ resolved virtual methods doesn't appear before the hang, so I
> unfortunately misspoke in my previous post.  With the -g, it does appear.

Can you provide a simple, complete example that demonstrates the problem?

Phil