> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4