[Python-ideas] Subprocess: Add an encoding argument

Nick Coghlan ncoghlan at gmail.com
Wed Sep 3 00:20:17 CEST 2014


On 3 Sep 2014 07:30, "Terry Reedy" <tjreedy at udel.edu> wrote:
>
> On 9/2/2014 9:25 AM, Nick Coghlan wrote:
>>
>> On 2 September 2014 07:15, Paul Moore <p.f.moore at 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
>
>
> I would expect something call Textxxx to present with (text) strings, not
bytes.

Exactly.

>> that wraps the streams as strict UTF-8 by default and allows the
>
>
> But this implies to me that I would still get (encoded) bytes.

I'm not sure how that follows - TextPopen is making the assumption
*because* it is providing a str based API, and thus needs to know the
appropriate text encoding details.

>> encoding and errors arguments to be either strings (affecting all
>> pipes) or a dictionary mapping "stdin", "stdout" and "stderr" to
>> individual settings.
>
>
> What I would want is automatic conversion of strings to encoded bytes on
send to the pipe and automatic reconersion of encoded bytes to strings on
received.  For that, there is little reason I can think of to use anything
other than utf-8

Still plenty of other applications that use other encodings (and as I
suggested to Paul, the real stress test for any proposed API is using it to
call iconv to do an encoding conversion).

>> With that, the simple utf-8 example just becomes:
>>
>>    with TextPopen(cmd, stdout=PIPE) as p:
>>        for line in p.stdout:
>>            process(line)
>
>
> Would type(line) be str or bytes?

str, otherwise this wouldn't be any different to the existing Popen
behaviour.

Cheers,
Nick.

>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140903/5df3f6c5/attachment.html>


More information about the Python-ideas mailing list