Dirk Heise writes:
But i have one further question: To have python shadow classes that wrap C++ classes, one can use SWIG. Doesn't it make more sense to extend the SWIG shadow class concept or its C++ parsing capabilities (if necessary) than writing your PyObject-derived C++ classes? I don't see the advantage. In Python, you do not need to model a class hierarchy of wrapper classes to resemble the inheritance of the wrapped C++ classes. Every wrapper class can be solo.
Excuse me if this sounds blasphemic, i just wanna know what's the advantage of the C++ binding compared to SWIGging, practically?
My impression (which may be wrong), is that the C++ binding effort is trying to come up with a more C++ friendly interface to Python that allows things like the ability to sub-class Python types, handle exceptions, and other things like that. Using this, it would presumably be easier to write C++ extension modules to Python (or to write extension modules in an entirely different manner than before). SWIG is mainly designed to automatically build Python extensions out of existing C/C++ code. I personally see SWIG as being entirely different than the C++ binding effort (in that SWIG doesn't really care what the C/C++ interface to Python is as long as there is one). However, I could see SWIG being used as a tool to automatically wrap C++ classes into Python extensions using the C++ binding. To my knowledge, no one has tried modifying SWIG to do this, but it would be possible in principle. As for a comparision between the C++ binding and SWIG shadow classes, I don't have any first-hand experience with that. However, if the C++ binding provides a similar capability, the main difference would probably be a performance improvement (the C++ binding would presumably be faster). Cheers, Dave _______________ C++-SIG - SIG for Development of a C++ Binding to Python send messages to: c++-sig@python.org administrivia to: c++-sig-request@python.org _______________