Message148025
I discovered this same problem recently when updating the subprocess docs, and also in working on the improved shell invocation support I am proposing for 3.3 (#13238).
I initially posted an earlier variant this suggestion as a new issue (#13442), but Victor redirected me here.
Firstly, I don't think it makes any sense to set encoding information globally for the Popen object. As a simple example, consider using Python to write a test suite for the iconv command line tool: there's only one Popen instance (for the iconv call), but different encodings for stdin and stdout.
Really, we want to be able to make full use of Python 3's layered I/O model, but we want the subprocess pipe instances to be slotted in at the lowest layer rather than creating them ourselves.
The easiest way to do that is to have a separate class that specifies the additional options for pipe creation and does the wrapping:
class TextPipe:
def __init__(self, *args, **kwds):
self.args = args
self.kwds = kwds
def wrap_pipe(self, pipe):
return io.TextIOWrapper(pipe, *self.args, **self.kwds)
The stream creation process would then include a new "wrap = getattr(stream_arg, 'wrap_pipe', None)" check that is similar to the existing check for subprocess.PIPE, but invokes the method to wrap the pipe after creating it.
So to read UTF-8 encoded data from a subprocess, you could just do:
data = check_stdout(cmd, stdout=TextPipe('utf-8'), stderr=STDOUT) |
|
Date |
User |
Action |
Args |
2011-11-21 01:56:37 | ncoghlan | set | recipients:
+ ncoghlan, amaury.forgeotdarc, pitrou, vstinner, mark, segfaulthunter, srid, mightyiam |
2011-11-21 01:56:37 | ncoghlan | set | messageid: <1321840597.06.0.979705999952.issue6135@psf.upfronthosting.co.za> |
2011-11-21 01:56:36 | ncoghlan | link | issue6135 messages |
2011-11-21 01:56:36 | ncoghlan | create | |
|