NEWBIE: Extending Python with C

[Alex Martelli]

engsol at teleport.com wrote:
   ...
> What I want to do is call (or invoke) a C exe  from Python, and return the
> results to Python. Or pass values of some sort to the C exe, and again
   ...
> I'm using Python 222 on NT. If I understood how to do  "Hello world" (in
> C, called from Python), I might be able to go from there.

Then you have a mind-boggling array of possibilities to perform
the task you require.

Simplest:

hello.c:
#include <stdio.h>
int main()
{
    puts("Hello world");
    return 0;
}

compile and link hello.c to produce hello.exe, say specifically placed
in c:\kraip\hello.exe.

Now in python hello1.py:
import os
os.system('c:/kraip/hello.exe')


This does the "call or invoke" part but doesn't really "return the
results to Python" -- hello.exe doesn't really have "results" but
rather performs output to standard-output, and invoking it with
os.system just lets it perform its output normally.  To capture
hello.exe's resulting output as a string for Python use,
hello2.py:
import os
hellopipe = os.popen('c:/kraip/hello.exe', 'r')
results = hellopipe.read()
hellopipe.close()

print "Python here: %r" % results


This limits the "pass values of some sort" spec to passing
starting arguments to the other program you're invoking.  E.g.
hello3.c:
#include <stdio.h>
int main(int args, char** argv)
{
    printf("Hello %s\n", argv[1]);
    return 0;
}

and hello4.py:
import os
argument = 'pythonista'
hellopipe = os.popen('c:/kraip/hello3.exe %s' % argument, 'r')
results = hellopipe.read()
hellopipe.close()

print "Python here: %r" % results


This is more or less the end of the line in terms of what
os.popen can offer -- due to buffering and suchlike there's
no practical way for python to drive BOTH standard input
and standard-output of another external program.

What you'll read about as EXTENDING python doesn't use an
external PROGRAM but rather an external MODULE, which in
Windows will take the form of a .DLL file.

But Windows in particular offers many other approaches too.
DDE (old and cranky), Windows Messages (old but OK for simple
things), COM (not newest any more, but still VERY powerful
and well-designed), not to mention many other possibilities
such as shared memory ("file mappings") and other kernel
objects for inter-process communication, "named pipes", etc.

And in platform-independent terms, there's XPCOM (a sort of
open-source clone of COM), Corba, XML-RPC, SOAP -- just for
starters.


Back when I did Windows programming full-time for a few
years, I would have reached for COM almost by reflex.  Now
that most of my programming is cross-platform or even Linux
specific, the reflex has dimmed a bit (I *do* miss COM, darn
it -- only technical aspect of Windows I do miss!), so I
would consider forgetting the "call (or invoke) a C exe"
part of the specs, deeming it an unfortunate slip of the
tongue, and go for Python extension and embedding (even
though it means that either the C-coded thingy will be a
DLL, NOT an exe, or else if it's an exe IT will have to
start the ball rolling by calling (or invoking) Python, not
vice-versa).
Even within this compass, you have so many choices it hurts:
C-level coding for the "Python-C API"; C++ use with SCXX,
CXX, Boost Python, SIP (yes you've specified C, not C++, but
people sometimes say one thing while they mean another...);
and SWIG, too.

The best way to choose is to delineate as precisely as you
can all constraints and possible future developments of
your needs.  If such constraints and futures do not include
using any other platform except Windows, then COM is most
likely still best: by exposing a COM/Automation model from
your EXE, not only will you let Python drive it, BUT you'll
have a potentially important "bullet point" on your app's
feature list for marketing purposes -- sophisticated
customers or 3rd party integrators will also be able to
drive your app from (e.g.) Visual Basic, Delphi, etc; and
even get an automatic dotNET wrapper to drive said app
from C# and the like, too.  This DOES help sell...


Alex