STINNER Victor <victor.stin...@haypocalc.com> added the comment: > ... it always seems to use the local 8-bit encoding
The locale encoding is not necessary a 8-bit encoding, it can by a multibyte like... UTF-8 :-) -- subprocess.patch: You should maybe use io.open(process.stdout.fileno(), encoding=..., errors=...) instead of codecs.getreader/getwriter. The code will be closer to Python 3. I think that the io module has a better support of unicode than codec reader/writer objects and a nicer API. See: http://bugs.python.org/issue8796#msg106339 -- > ... allowing [encoding and errors] to accept either a single string > (as now), or a dict with keys 'stdin', 'stdout', 'stderr' I like this idea. But what about other TextIOWrapper (or other file classes) options: buffer size, newline, line_buffering, etc.? Why not using a dict for existing stdin, stdout and stderr arguments? Dummy example: process = Popen( command, stdin={'file': PIPE, 'encoding': 'iso-8859-1', 'newline': False}, stdout={'file': PIPE', 'encoding': 'utf-8', 'buffering': 0, 'line_buffering': False}, ...) If stdin, stdout or stderr is a dict: the default value of its 'file' key can be set to PIPE. I don't think that it's possible to choose the encoding, buffer size, or anything else if stdin, stdout or stderr is not a pipe. With this solution, you cannot specify the encoding for stdin, stdout and stderr at once. You have at least to repeat the encoding for stdin and stdout (and use stderr=STDOUT). -- I still hesitate to accept this feature request. Is it really needed to add extra arguments for TextIOWrapper? Can't the developer create its own TextIOWrapper object with all interesting options? In Python 3, be able to specify stdout encoding is an interesting feature. Control the buffers size is also an interesting option. My problem is maybe the usage of a dict to specify various options. I'm not sure that it is extensible to support future needs. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6135> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
