How to execute foreing code from Python

[Hidura]

Thanks to all for your fast responses. I will use this on a server
running on Linux, so there is no problem with the OS and probably i
will try to pipes and subprocess, but the pipes worry me because i
can't stop the process using timeout or i don't found how to stop
it...


2011/1/23, Dan Stromberg <drsalists at gmail.com>:
> 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.
>

-- 
Enviado desde mi dispositivo móvil

Diego I. Hidalgo D.