[PYTHON C++-SIG] LLNL Python/C++ integration: current status

[David Ascher]

Hi all.

Geoff said:
> Anyway, the result of this is that autoconf now allows building a
> python, either with or without C++ support.  Without it, you get
> exactly the python you would've gotten in the first place.  With it,
> you get a better python, one that can support C++ extension modules.

Just a question: how do you deal with frozenmain.c?  Do you treat it
as a C++ file?  

I assume you've also modified the .c files to do the appropriate 
extern "C" {...} stuff...
 
> To accomplish this, we have built a C++ extension module which
> provides the capability to invoke C++ member functions directly from
> Python.  This is accomplished by mimicking the "function object"
> support in Python, with a new "member function object" type, which has
> the internal data necessary to allow a C++ method invocation.  The
> Py_FindMethod() function has been succeeded by a new getattr assister
> named FindMemberFunc().  This function builds a C++ member function
> object corresponding to the requested member function for a C++ python
> extension class.  When Python calls this member function object, a
> trampoline function is called which extracts the necessary data from
> member function object, which allows it to invoke the C++ member
> function on the object.

Cool.

> [description of argument tuplification to callbacks which I didn't
> mean to delete]

Is it possible to have the argument detuplification and parsing
automated when so desired?  So that if I specify a callback as expecting
2 ints, I can define those in the method definition and the 'system'
will deal with the ArgTuple handling?  It seems it would be a nice
feature, if it's possible [this is getting into areas of C++ that I
don't know well].
 
> Finally, our C++ wrapper over the Python C API allows the abolition of
> all NULL checking.  Instead, Python exceptions raised by Python C API
> functions are converted directly into C++ exceptions, which begin

Very nice.

> #include <iostream.h>
> 
> #include "PythonX.hh"

This maybe too late, but 'PythonX' makes me think of Python/ActiveX, which
is a completely different system...  
 
> This is the C++ language as we know it, and we are not buckling under
> on making a quality interface on account of compiler vendors who don't
> support the language as the C++ committee defines it.  This may well
> mean that certain C++ compilers in the market place will not compile
> this code.  If you have such a compiler, you will need to wait until
> your compiler is upgraded to a level conformant with the language
> spec, before you will be able to use this.

This is not at all a criticism, but I'm curious: does the latest g++
qualify?  I think this will have at least some impact on the public
reaction to your system.
 
> The code described in this note will be available to others.  We have
> not made clear release plans/schedules yet.  It would be useful to
> get a reading on how much interest there is in this.  Certainly it is
> an ongoing development effort, with all the cautionary statements
> about instability that go along with that.  Nevertheless, we are
> highly motivated to get it into a stable form for our own purposes,
> and are prepared to cut occasional patch sets for external use.

What are your thoughts regarding eventual integration in the main source
distribution?  It strikes me that such an integration would be a very
worthwhile effort, but I realize it is not one without compromises or
headaches.
 
This sounds really impressive -- congratulations to all involved.

--david ascher

_______________
C++-SIG - SIG for Development of a C++ Binding to Python

send messages to: c++-sig at python.org
administrivia to: c++-sig-request at python.org
_______________