On 2 September 2014 07:15, Paul Moore <p.f.moore@gmail.com> wrote:
The find -print0 example is out of scope, IMO, as newline handling is different from encoding. At some point, it becomes easier to manually wrap the streams rather than having huge numbers of parameters to the Popen constructor.
Don't forget Antoine's suggestion of creating a TextPopen subclass that wraps the streams as strict UTF-8 by default and allows the encoding and errors arguments to be either strings (affecting all pipes) or a dictionary mapping "stdin", "stdout" and "stderr" to individual settings. With that, the simple utf-8 example just becomes: with TextPopen(cmd, stdout=PIPE) as p: for line in p.stdout: process(line)
I'll think some more on this...
For your torture test, consider the "iconv" (or "win_iconv") utility, which does encoding conversions, and how you might test that from a Python program without needing to do your own encoding and decoding, but instead let the subprocess module handle it for you :) (There's a flip side to that problem which is the question of *writing* an iconv utility in Python 3, and that's why there's an open RFE to support changing the encoding of an existing stream) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia