[Paul]
We could make integrating C++ and Python easier through CXX or Py_Cpp. Perhaps we should ship one of those with Python 2.1. Anyhow, integrating C++ and Python is not really so hard, in my experience.
... or a number of others (but SWIG falls very short when it comes to things like C++ references)... [Marc-Andre]
Ok, you can use SWIG to get most of the work done, but the interface between the C++ object world and the Python object world is one big mess -- all implementations I've seen use shadow objects or proxies to interface from one to the other... with lots of temporary objects used for the linkup.
While I agree it's messy, those are not the objectionable qualities. Any refcounted C++ system is going to have proxies (smart pointers / refcounting stack-safe "reference" objects to the real heap-based objects). And while I think we'd be better off with a C++ implementation, I would warn that C++'s notion of inheritence is in conflict with Python's. It won't be "as above, so below" (unless we screw interpreting and go straight to native code). Assuming that the class / type dichotomy actually gets healed, that is.
... The real argument here is that we can push the type logic one layer further down. Ideal would be a level of integration such as the one implemented in JPython or Jython.
Nope. If you heal the class / type split, there's really only one underlying type object. Unless you go the other way, and write "native" code (as JPython does). All of the existing C++ interfaces / helpers deal only with type objects (at least, those that I've examined, which is most of them). In fact, only ExtensionClass attempts to deal with the class / type split, and while it's a masterpiece, I think it's a great example of everything to avoid in Py3K. - Gordon