[Python-Dev] new popen for win32! [status update]

Guido van Rossum guido@beopen.com
Sun, 09 Jul 2000 21:09:04 -0500

> oh, I just changed things around the other way (assuming that
> "popen2" was some kind of standard).
> changing things is trivial, decided what's the right way to do it
> is harder.  here's another idea:
> one way to solve this would be to deprecate "popen2", and move
> that functionality into the os module -- with the return values
> sorted out.  that is, let's introduce:
>     f = os.popen(cmd, mode, bufsize)
>     w, r = os.popen2(cmd, mode, bufsize)
>     w, r, e = os.popen3(cmd, mode, bufsize)
>     w, r = os.popen4(cmd, mode, bufsize) # windows only, at the moment
> and mark popen2 as obsolete.
> whaddayathink?

Ah, I finally see the problem here.  Sigh...  Both orders are equally
logical -- depending on your point of view!  This is of course because
pipes have a read end and a write end.  So stdin is read by the child
but written by the parent, and stdout is written by the child and read
by the parent.

From the parent's point of view, it almost makes sense to put stdout
first and stdin second, because this is the familiar order (read,
write).  I believe this was the original reasoning when popen2 was
created (and there was no popen3).  Unfortunately it doesn't extend
for popen3.

So the best order to keep our sanity is really to return
(stdin,stdout,stderr), with the understanding that, as this is the
parent, stdin must be *written* and stdout/stderr must be *read*.

I still can't figure out whether this is what your latest patch does
(wouldn't it make sense if os.popen2 and os.popen3 were also available
on Unix?) but that's how it should be.  Sorry if I confused you more.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)