[Python-Dev] Gradual migration

[Gordon McMillan]

[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