How to execute foreing code from Python

[Dan Stromberg]

On Sun, Jan 23, 2011 at 4:24 PM, Dave Angel <davea at ieee.org> wrote:
> On 01/-10/-28163 02:59 PM, hidura at gmail.com wrote:
>>
>> Hello i want to code from different languages using a Python script i
>> know i can use os.system, but i don't know how to receive data or send
>> arguments using that method if theres any another way to make it or
>> there's a way to send arguments and receive data using os.system?
>>
>> Thanks in advance.
>>
>
> That sentence runs on, and makes no sense to me.  But I can guess that you
> would like to be able to write code in other languages, and call it from
> within a Python script.

Well, clearly it made some sense, or you wouldn't be responding.

> If you're on Windows, and the other language is a compiled one like C,
> compile it into a DLL, and call that DLL from Python.  Ctypes is the first
> module to study.

The DLL is but a weak mimicry of what *ix had for a long time before.
On most *ix's, the .so is the analog to the windows DLL, though only
AIX appears to suffer from the same kind of "DLL hell" that windows
suffers from (which makes some historical if not technical sense,
given that windows is related to OS/2, which like AIX is also from
IBM).  Using a .so, you can still use ctypes.  You also have the
option of using Cython, which is perhaps a bit better supported on
*ix, but will likely now work on windows too.

> If you're on Linux, and the code in the other language was written by
> someone else, and is already compiled into an executable you cannot change,

This is rare on Linux - almost everything is changeable on Linux,
because it is almost entirely opensource - sometimes entirely so,
depending on distribution choice and what 3rd party apps you install
after the OS install.

> you probably should invoke it using the subprocess module.

This is an option on almost any OS, and in fact is probably a pretty
good one on almost any OS, even if you do have source.  Sadly, few
windows programs are written to take advantage of this, perhaps
because of the historical (dos/windows) command.com's fake pipes.

You can communicate with a subprocess using pipes, or command line
arguments, or files, or sockets, or shared memory.  There are probably
other options that aren't coming to mind just now.  But usually, using
pipes gives the loosest (best) coupling between processes.

Microsoft appears to have recognized this to some extent by releasing
powershell - though it uses object pipes rather than byte stream
pipes.  Object pipes appear to require less serialization, but also
appear to be less loosely coupled.  For remote pipes, powershell
serializes to XML, while *ix pipes serialize exactly the same way
remote local or remote.