Only when the program has executed and the output available, subprocess can
read through PIPE's stdout it seems ( not at any other time).
With killing, I loose the output.
This is untrue.
process.stdout.read() # Blocks until end of stream.
process.stdout.read(1) # Reads one character, only blocks if that character is unavailable.
As such you can read the needed chars from the child's STDOUT one at a
time. For example:
stop = False
ping = subprocess.Popen('ping 127.0.0.1', shell = True, stdout =
stop = True
while not stop:
This solution let's you read from the stdout of a program that may
never terminate and time out after a certain amount of time but it's
not pretty. It's unix specific and introduces threads into a program
that doesn't need them. I'd go with trying to limit the time the
child runs through command line options if at all possible.
From http Wed Jul 4 22:22:12 2007
From: http (Paul Rubin)
Date: 04 Jul 2007 13:22:12 -0700
Subject: PEP 3107 and stronger typing (note: probably a newbie question)
John Nagle <nagle at animats.com> writes:
This has been tried. Original K&R C had non-enforced static typing.
All "struct" pointers were equivalent. It wasn't pretty.
It takes strict programmer discipline to make non-enforced static
typing work. I've seen it work in an aerospace company, but the Python
crowd probably doesn't want that level of engineering discipline.
I think even enforced static types wouldn't cure what I see as the
looseness in Python. There is not enough composability of small
snippets of code. For example, the "for" statement clobbers its index
variable and then leaks it to the outside of the loop. That may be
more of a culprit than dynamic types. Perl and C++ both fix this with
for (my $i in ...) ... (perl) or
for (int i = 0; i < n; i++) ... (C++, Java)
making a temporary scope for the index variable. Python even leaks
the index variable of list comprehensions (I've mostly stopped using
them because of this), though that's a recognized wart and is due to
Python would be helped a lot by some way to introduce temporary
scopes. We had some discussion of this recently, concluding that
there should be a compiler warning message if a variable in a
temporary scope shadows one from a surrounding scope.