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 <drsali...@gmail.com>: > On Sun, Jan 23, 2011 at 4:24 PM, Dave Angel <da...@ieee.org> wrote: >> On 01/-10/-28163 02:59 PM, hid...@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. -- http://mail.python.org/mailman/listinfo/python-list
