[Python 2.4/2.5] subprocess module is sorely deficient?

[A.T.Hofkamp]

On 2008-04-22, Harishankar <v.harishankar at gmail.com> wrote:
> Hi,
>
> Sorry to start off on a negative note in the list, but I feel that the Python 
> subprocess module is sorely deficient because it lacks a mechanism to:
>
> 1. Create non-blocking pipes which can be read in a separate thread (I am 

I don't know about threading, but you can read/write streams in a non-blocking
way in Python (under Linux) with the os.read/os.write functions (these map
directly to read(2)/write(2) primitives). You should first check that something
can be read/written. Use eg select.select() for this. Several GUI toolkits also
allow monitoring of file handles.

Whether this also works at other OSes, I don't know.


Alternatively, you can create your own pipes, make them non-blocking, and give
the file handles to subprocess.


> 2. Kill the subprocess in a platform independent manner (i.e. no third party 
> modules and no hacks).

The concept of sub-process is platform dependent already.

Usually however, closing the child input stream is sufficient for most child
programs to decide that they can quit.

> Is there any way to use non-blocking Popen objects using subprocess? and 2 - 
> is there a way to kill the subprocess in a platform independent manner in a 
> purely Pythonic way? I thought initially that this problem is simple enough, 
> but over the last couple of days I've been really struggling to find any 
> answer. I've been through dozens of mailing list archives in to find a 
> solution. Unfortunately none of the solutions seem to fit my needs.

Interfacing with the rest of the world implies you are going to need services
provided by the OS at one time or another. Python is rather transparent here
and gives you quick access to the OS services.

While this is bad for uniformity, it is good to let people make their own
choices in optimally using the OS services. Python helps here by giving
light-weight access to the underlying OS, making explicit what part is OS
dependent.

(and if still in doubt, why do you think were all the solutions you found 'not
fitting'?).

> My only solution seems to be to offer the end user the mencoder command line 
> and make them execute it manually and be done with it but that seems a rather 
> weak solution.

This is always a good fallback.


Sincerely,
Albert