> 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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
