[Python-ideas] changing sys.stdout encoding

[Nick Coghlan]

On Wed, Jun 13, 2012 at 3:21 PM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Jun 12, 2012 at 9:58 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>> Oscar Benjamin writes:
>>
>>  > I also think I missed something in this thread. At the beginning of the
>>  > original thread it seemed that everyone was agreed that
>>  >
>>  >   writer = codecs.getwriter(desired_encoding)
>>  >   sys.stdout = writer(sys.stdout.buffer)
>>  >
>>  > was a reasonable solution (with the caveat that it should happen before any
>>  > output is written). Is there some reason why this is not a good
>>  > approach?
>>
>> It's undocumented and unobvious, but it's needed for standard stream
>> filtering in some environments -- where a lot of coding is done by
>> people who otherwise never need to understand streams at anything but
>> a superficial level -- and the analogous case of a newly opened file,
>> pipe, or socket is documented and obvious, and usable by novices.
>>
>> It's damn shame that we can't say the same about the stdin, stdout,
>> and stderr streams (even if I too have been at pains to explain why
>> that's hard to fix).
>
> I'm probably missing something, but in all my naivete I have what
> feels like a simple solution, and I can't seem to see what's wrong
> with it.

I think you're right, and such a method in combination with
stream.buffer.peek() should actually handle a lot of encoding
detection cases, too.

The alternative approaches (calling TextIOWrapper on stream.detach(),
or open on stream.fileno()) either break any references to the old
stream or else create two independent IO stacks on top of a single
underlying file descriptor, which may create some odd behaviour.

Being able to set the encoding on a previously unused stream would
also interact better with the existing subprocess PIPE API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia