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

[R. David Murray]

On Sat, 29 Mar 2014 16:30:25 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 29 Mar 2014 04:44:32 -0400
> Terry Reedy <tjreedy at udel.edu> wrote:
> > On 3/28/2014 5:12 PM, Antoine Pitrou wrote:
> > > On Fri, 28 Mar 2014 16:58:25 -0400
> > > Terry Reedy <tjreedy at udel.edu> wrote:
> > 
> > >> However, the code below creates a subprocess for one command and one
> > >> response, which can apparently be done now with subprocess.communicate.
> > >> What I and others need is a continuing (non-blocking) conversion with 1
> > >> and only 1 subprocess (see my response to Josiah), and that is much more
> > >> difficult. So this code does not do what he claims his will do.
> > >
> > > Why don't you use multiprocessing or concurrent.futures? They have
> > > everything you need for continuous conversation between processes.
> > 
> > I have not used either and no one suggested either before, while Amaury 
> > Forgeot d'Arc and Guido suggested subprocess pipes. I added those two 
> > ideas to the issue.
> 
> Looking at idlelib/rpc.py, it looks largely like an uncommented
> (untested?) reimplementation of multiprocessing pipes, with weird
> architecture choices (RPCServer is actually a client?).

I think instead we might call a "pre" implementation :)
I'm pretty sure this Idle stuff existed before multiprocessing did.

(In English, 'reimplementation' implies that multiprocessing existed
already, and therefore implies someone looked at it and copied the
concepts in it it badly, which is not the case as far as I'm aware.)

--David