[PyKDE] Help with SIP
phil at riverbankcomputing.co.uk
Fri Dec 24 13:49:22 GMT 2004
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
> 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?
More information about the PyQt