While http://bugs.python.org/issue2683 did clarify the fact that the .communicate API takes a byte stream as input, it is easy to miss the implication.  Because Python programs start up with stdin as a text stream, it might be good to point out that some action may need to be taken to be sure that the receiving program expects a byte stream, or that the byte stream supplied should be in an encoding that the receiving program is expecting and can decode appropriately.

No mention is presently made in the documentation for .communicate that its output is also a byte stream, and if text will correspond to whatever encoding is used by the sending program.

Maybe it should also be mentioned that p.stdout and p.stderr and p.stdin, when set to be PIPEs, are also byte streams.  Of course that is the reason that communicate accepts and produces byte streams.

I've created a patch that updates the docs to reflect the behavior of communicate() and check_output(), which is that both the "input" argument and stdin/stdout/stderr PIPEs will convert to and from strings when self.univeral_newlines is True and must be bytes otherwise.

New changeset 267fff541bda by Andrew Kuchling in branch 'default':
#10481: describe universal_newlines' effect on communicate()/check_output() output (alternately bytes or strings)
http://hg.python.org/cpython/rev/267fff541bda

Thanks for your patch!