views:

1101

answers:

6

I want to extend a large C project with some new functionality, but I really want to write it in Python. Basically, I want to call Python code from C code. However, Python->C wrappers like SWIG allow for the OPPOSITE, that is writing C modules and calling C from Python.

I'm considering an approach involving IPC or RPC (I don't mind having multiple processes); that is, having my pure-Python component run in a separate process (on the same machine) and having my C project communicate with it by writing/reading from a socket (or unix pipe). my python component can read/write to socket to communicate. Is that a reasonable approach? Is there something better? Like some special RPC mechanism?

Thanks for the answer so far - however, i'd like to focus on IPC-based approaches since I want to have my Python program in a separate process as my C program. I don't want to embed a Python interpreter. Thanks!

+6  A: 

I recommend the approaches detailed here. It starts by explaining how to execute strings of Python code, then from there details how to set up a Python environment to interact with your C program, call Python functions from your C code, manipulate Python objects from your C code, etc.

EDIT: If you really want to go the route of IPC, then you'll want to use the struct module. Most communication between a Python and C process revolves around passing structs back and forth, either over a socket or through shared memory.

I recommend creating a Command struct with fields and codes to represent commands and their arguments. I can't give much more specific advice without knowing more about what you want to accomplish, but in general I recommend the protlib library, since it's what I use to communicate between C and Python programs (disclaimer: I am the author of protlib).

Eli Courtwright
I've done this before and it worked out well. I had several C processes that communicated by sending structs over a socket and wanted to allow python processes too. Writing the protocol stuff was trivial in python and I was able to write a Python script that ran as part of the build to autocreate the Python code to pack/unpack the C structs by parsing the .H files. Only problem is due to all the string packing/unpacking, performance isn't nearly what you would get with native C acting directly on the binary representation of the structs just memcopy and casting the raw data off the socket.
bdk
+3  A: 

See the relevant chapter in the manual: http://docs.python.org/extending/

Essentially you'll have to embed the python interpreter into your program.

janneb
+1  A: 

Have you considered just wrapping your python application in a shell script and invoking it from with in your C application?

Not the most elegant solution, but it is very simple.

hhafez
Indeed if he wants to run Python in a separate process and talk to it over stdin/stdio, that's just about the best solution.
Crashworks
+1  A: 

I haven't used an IPC approach for Python<->C communication but it should work pretty well. I would have the C program do a standard fork-exec and use redirected stdin and stdout in the child process for the communication. A nice text-based communication will make it very easy to develop and test the Python program.

D.Shawley
Is fork-exec possible on Windows? Not sure what the questioner's platform is.
Craig McQueen
There is a (barely) documented way to do fork-exec under Windows, but I wouldn't do it there. He mentioned unix sockets so I'm assuming that the target isn't Windows. I guess it would be more like spawn and pipe under Windows.
D.Shawley
+1  A: 

If I had decided to go with IPC, I'd probably splurge with XML-RPC -- cross-platform, lets you easily put the Python server project on a different node later if you want, has many excellent implementations (see here for many, including C and Python ones, and here for the simple XML-RPC server that's part the Python standard library -- not as highly scalable as other approaches but probably fine and convenient for your use case).

It may not be a perfect IPC approach for all cases (or even a perfect RPC one, by all means!), but the convenience, flexibility, robustness, and broad range of implementations outweigh a lot of minor defects, in my opinion.

Alex Martelli
A: 

apparently Python need to be able to compile to win32 dll, it will solve the problem

In such a way that converting c# code to win32 dlls will make it usable by any development tool

Arabcoder
This only applies to win32 platform :-p What about Unix?
Pharaun