Message222740
I've tested it and setting PYTHONIOENCODING='utf-8-sig' starts to get there. It causes Python to consume the BOM on stdin, but it also causes stdout to print a spurious non-printable character in the output:
C:\Users\jaraco> echo foo | ./print-input
foo
There is a non-printable character before foo. I've included it in this message. In Powershell, it's rendered with a square before foo:
□foo
Using PowerShell under ConEmu, it appears as a space:
foo
In cmd.exe, I see this:
C:\Users\jaraco>python -c "print('foo')"
foo
The space before the 'foo' apparently isn't a space at all.
Indeed, the input is being processed as desired, but the output now is not.
C:\Users\jaraco> python -c "print('bar')"
bar
(the non-printable character appears there too)
If I copy that text to the clipboard, I find that character is actually a \ufeff (zero-width no-break space, aka byte order mark). So by setting the environment variable to use utf-8-sig for input, it simultaneously changes the output to also use utf-8-sig.
So it appears as if setting the environment variable would work for my purposes except that I only want to alter the input encoding and not the output encoding.
I think my goal is pretty basic - read text from standard input and write text to standard output on the primary shell included with the most popular operating system. I contend that goal should be easily achieved and straightforward on Python out of the box.
What does everyone think of the proposal that Python should simply default to utf-8-sig instead of utf-8 for stdin encoding? |
|
Date |
User |
Action |
Args |
2014-07-11 13:01:27 | jaraco | set | recipients:
+ jaraco, lemburg, loewis, vstinner, ezio.melotti |
2014-07-11 13:01:26 | jaraco | set | messageid: <1405083686.97.0.237614728685.issue21927@psf.upfronthosting.co.za> |
2014-07-11 13:01:26 | jaraco | link | issue21927 messages |
2014-07-11 13:01:26 | jaraco | create | |
|