[Python-Dev] Gradual migration
Thu, 26 Oct 2000 10:49:20 -0400
> > 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)...
> 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.