in example - in child process and reads and writes standard streams to converse with it over two pipes example - pp \system\processes\pipes-testchild py import ostimesys mypid os getpid(parentpid os getppid(sys stderr write('child % of % got arg"% "\ (mypidparentpidsys argv[ ])for in range( )time sleep( make parent process wait by sleeping here recv input(stdin tied to pipecomes from parent' stdout time sleep( send 'child % got[% ](mypidrecvprint(sendstdout tied to pipegoes to parent' stdin sys stdout flush(make sure it' sent now or else process blocks the following is our test in action on cygwin (it' similar other unix-like platforms like linux)its output is not incredibly impressive to readbut it represents two programs running independently and shipping data back and forth through pipe device managed by the operating system this is even more like client/server model (if you imagine the child as the serverresponding to requests sent from the parentthe text in square brackets in this output went from the parent process to the child and back to the parent againall through pipes connected to standard streams[ :\pp \system\processes]python pipes py child of got arg"spamparent got"child got[hello from parent ]parent got"child got[hello from parent ]output stream buffering revisiteddeadlocks and flushes the two processes of the prior section' example engage in simple dialogbut it' already enough to illustrate some of the dangers lurking in cross-program communications first of allnotice that both programs need to write to stderr to display messagetheir stdout streams are tied to the other program' input stream because processes share file descriptorsstderr is the same in both parent and childso status messages show up in the same place more subtlynote that both parent and child call sys stdout flush after they print text to the output stream input requests on pipes normally block the caller if no data is availablebut it seems that this shouldn' be problem in our example because there are as many writes as there are reads on the other side of the pipe by defaultthoughsys stdout is buffered in this contextso the printed text may not actually be transmitted until some time in the future (when the output buffers fill upin factif the flush calls are not madeboth processes may get stuck on some platforms waiting for input from the other--input that is sitting in buffer and is never flushed out over the pipe they interprocess communication