[Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

[Guido van Rossum]

On Fri, Mar 28, 2014 at 9:45 AM, Josiah Carlson <josiah.carlson at gmail.com>wrote:

>
> 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:
> http://pastebin.com/0LpyQtU5
>

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.

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).

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.

If it were me, I'd define three methods, with longer names to clarify what
they do, e.g.

proc.write_nonblocking(data)
data = proc.read_nonblocking()
data = proc.read_stderr_nonblocking()

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.)

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.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140328/a65cea55/attachment.html>