[PyKDE] SIP and SWIG communication

Alexandre Courbot alexandrecourbot at linuxgames.com
Sun Jun 8 13:51:00 BST 2003


> sipThis is the internal (to SIP) Python object that contains the real C++
> pointer. It doesn't exist in SIP v4.
>
> The C++ SIP API provides you with all the functionality you need - but this
> is not exposed at the Python level, so you may need a C++ glue layer.

I'd suggest that you provide a way to get the adress of the C++ wrapped object 
and constructors from raw pointers from Python, like SWIG does. It wouldn't 
do anything bad to PyQt but would greatly improve the connectivity of SIP 
wrapped applications.

It would be even better, if the different wrappers teams (SIP, SWIG, boost) 
could discuss about connectivity and agree on either a low-level building 
layer accessible from Python, either some common rules that would make 
communication transparent. I am not in any way a SWIG fanatic, but I find its 
ability to construct objects from raw pointers (and to get the adress of the 
wrapped object) very convenient from a user point of view.

I think it's a critical problem for PyQt. I for myself am very enthousiast to 
use it, but unless I can't solve this problem, I'll eventually have to write 
my editors using Qt directly, in C++.

After all, I'd have no problem if I want to use Qt with my library using C++. 
Why would I have to face problems if I want to do the same in Python?

> The other alternative, of course, is to re-wrap the library using SIP. How
> big is the library? Is there a URL for it?

The library is not that big - at least the wrappers doesn't have many entries. 
I haven't released the code for it yet since it's still quite unusuable. Its 
wrapping is made of several Python modules which must be aware of each other 
(i.e. they all use the same support library). SWIG does the job very well and 
I don't see any reason (apart from short-term usage of PyQt) to switch to 
SIP. Moreover, my lib mess with SWIG itself, so this would mean some changes, 
getting knowledge of SIP (which isn't very documented for now), and so on.

Well, I could leave without PyQt (of course, I'd be disappointed because I 
really find it great :( ), but IMO the communication problem should be a 
priority. I'm sure other potential users had to change their mind because of 
the same problem.

Thanks,
Alex.
-- 
http://www.gnurou.org




More information about the PyQt mailing list