The following code fails on Windows using Python 3.1

import os
fd = os.popen("foo.exe", "w")

It worked on Python 2.x where x=4,5 and 6

os.popen is obsolete and as I understand is removed from 3k. Use subprocess module instead.
http://docs.python.org/library/os.html?highlight=popen#os.popen

Well, actually os.popen in Python3 is implemented by calling subprocess.Popen.

So, Bob, how does it fail?

I could not get it to open a write pipe. I am trying to drive GNUplot 
from Python. It worked OK in Python 2.x but does not work well in 3.x.
I have it partially working now ... I am calling subprocess.Popen but I 
cannot get a text mode pipe which is disappointing. I have not yet got 
my head around Python 3's byte vs string stuff.

regards
Bob Buckley

On 21/03/2010 8:02 AM, R. David Murray wrote:
> R. David Murray<rdmurray@bitdance.com>  added the comment:
>
> Well, actually os.popen in Python3 is implemented by calling subprocess.Popen.
>
> So, Bob, how does it fail?
>
> ----------
> nosy: +r.david.murray
> priority:  ->  normal
> stage:  ->  test needed
>
> _______________________________________
> Python tracker<report@bugs.python.org>
> <http://bugs.python.org/issue8006>
> _______________________________________
>

A short snipped of example code that works in python2 and fails in python3 would be helpful in deciding whether or not this is a bug that needs fixing in python3.  Something that doesn't involve gnuplot, just python itself.

I've just run this:

<code>
import os
fd = os.popen("cat.exe", "w")

for i in range (100):
  _ = fd.write ("%d\n" % i)

fd.flush ()

</code>

and seen the expected list of numbers on the screen. cat.exe is from the gnuwin32 tools but I'm assuming that any equivalent .exe would do as well.

I suspect that the OP's issue may be with buffering, but I'd like to hear back. Switching to pending before closing as invalid. If the OP wishes to come back with a repeatable failing case I'm quite happy to look at it.

Sorry I didn't get back to you. Originally, I had trouble with just getting a pipe ... but updating my Python software seemed to make that problem go away.
I also had problems with Python 2.6 when drawing more complicated figures. I could not tell whether the issue of sending all the data via a pipe is with the Python Library, with GNUplot or with Windows pipes.
I also believe the problem I had was with buffering.
I had to get my code working so I found another solution (I write all my GNUplot commands to a file, then just send a "load file.txt" command via the pipe. I would like to be able to use pipes to communicate so I will try to use the new subprocess.Popen and Popen.communicate method and see if I can get that working reliably in 2.6 and 3.1
This will give me an idea about whether there is output from GNUplot that might be filling some buffer when using the os.popen method.

Closing as invalid - believed to be a buffering issue.