This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients Arfrever, amaury.forgeotdarc, berwin22, chris.jerdonek, eric.araujo, mark, martin.panter, mightyiam, ncoghlan, pitrou, r.david.murray, segfaulthunter, srid, vstinner
Date 2016-05-18.08:27:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1463560023.44.0.844871707607.issue6135@psf.upfronthosting.co.za>
In-reply-to
Content
Here is a tested illustration of how I would suggest to manually handle encoding with check_output():

>>> text_input = "©"
>>> args = ("iconv", "--from-code", "ISO_8859-1", "--to-code", "UTF-8")
>>> bytes_output = check_output(args, input=text_input.encode("iso-8859-1"))
>>> bytes_output
b'\xc2\xa9'
>>> bytes_output.decode("utf-8")
'©'

If you wanted actual universal newline translation (which is more than plain text encoding), it would be more complicated, but still possible.

But I am not hugely against adding new “encoding” and “errors” parameters. The reasons against are that I don’t see it as necessary, and there are already a lot of subprocess-specific options to wade through.
History
Date User Action Args
2016-05-18 08:27:03martin.pantersetrecipients: + martin.panter, amaury.forgeotdarc, ncoghlan, pitrou, vstinner, mark, eric.araujo, segfaulthunter, Arfrever, r.david.murray, srid, mightyiam, chris.jerdonek, berwin22
2016-05-18 08:27:03martin.pantersetmessageid: <1463560023.44.0.844871707607.issue6135@psf.upfronthosting.co.za>
2016-05-18 08:27:03martin.panterlinkissue6135 messages
2016-05-18 08:27:03martin.pantercreate