<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 28, 2014 at 9:45 AM, Josiah Carlson <span dir="ltr"><<a href="mailto:josiah.carlson@gmail.com" target="_blank">josiah.carlson@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div dir="ltr">If it makes you feel any better, I spent an hour this morning building a 2-function API for Linux and Windows, both tested, not using ctypes, and not even using any part of asyncio (the Windows bits are in msvcrt and _winapi). It works in Python 3.3+. You can see it here: <a href="http://pastebin.com/0LpyQtU5" target="_blank">http://pastebin.com/0LpyQtU5</a><span class="HOEnZb"></span></div>

</blockquote><div><br></div><div>Seeing this makes *me* feel better. I think it's reasonable to add (some variant) of that to the subprocess module in Python 3.5. It also belongs in the Activestate cookbook. And no, the asyncio module hasn't made it obsolete.<br>

<br></div><div>Josiah, you sound upset about the whole thing -- to the point of writing unintelligible sentences and passive-aggressive digs at everyone reading this list. I'm sorry that something happened that led you feel that way (if you indeed feel upset or frustrated) but I'm glad that you wrote that code snippet -- it is completely clear what you want and why you want it, and also what should happen next (a few rounds of code review on the tracker).<br>

</div><div><br></div><div>But that PEP? It's just a terrible PEP. It doesn't contain a single line of example code. It doesn't specify the proposed interface, it just describes in way too many sentences how it should work, and contains a whole lot of references to various rants from which the reader is apparently meant to become enlightened. I don't know which of the three authors *really* wrote it, and I don't want to know -- I think the PEP is irrelevant to the proposed feature, which is of "put it in the bug tracker and work from there" category -- presumably the PEP was written based on the misunderstanding that having a PEP would make acceptance of the patch easier, or because during an earlier bikeshedding round someone said "please write a PEP" (someone always says that). I propose to scrap the PEP (set the status to Withdrawn) and just work on adding the methods to the subprocess module.<br>

<br>If it were me, I'd define three methods, with longer names to clarify what they do, e.g.<br><br>proc.write_nonblocking(data)<br></div><div>data = proc.read_nonblocking()<br>data = proc.read_stderr_nonblocking()<br>

<br></div><div>I.e. add _nonblocking to the method names to clarify that they may return '' when there's nothing available, and have a separate method for reading stderr instead of a flag. And I'd wonder if there should be an unambiguous way to detect EOF or whether the caller should just check for proc.stdout.closed. (And what for stdin? IIRC it actually becomes writable when the other end is closed, and then the write() will fail. But maybe I forget.)<br>

</div><div><br></div><div>But that's all bikeshedding and it can happen on the tracker or directly on the list just as easily; I don't see the need for a PEP.<br><br></div></div>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>