[Python-ideas] changing sys.stdout encoding

[Jim Jewett]

On Fri, Jun 8, 2012 at 11:57 PM, Rurpy <rurpy at yahoo.com> wrote:
> On 06/07/2012 07:01 PM, Nick Coghlan wrote:
>> On Fri, Jun 8, 2012 at 10:14 AM, Rurpy <rurpy-/E1597aS9LQAvxtiuMwx3w at public.gmane.org> wrote:

>>>  sys.stdout = codecs.getwriter(opts.encoding)(sys.stdout.buffer)
>>> But that code is not obvious to someone who has been able to do
>>> all his encoded IO (with the exception of sys.stdout) using just
>>> the encoding parameter of open().

Well, you could do it with sys.stdout too, if you did as part of open.
 Unfortunately, by the time your code comes along, it is already open
-- and may well have already been written to.

> OK, I can see that as a use-case design principle.  I still
> don't see any hard technical reason why the same streams could
> not be kept and simply allow their encoding's to be reset if
> they haven't been used yet.

Unfortunately, that leads to very fragile code, that will break
unexpectedly because something totally unrelated decided to write a
license message to stdout.

> But networks, shared files systems, email, etc have all
> blurred the concept of localness.  Just because I am running
> my program on a Unix machine does not mean I may not need
> to write files with '\n\r' line endings.

So write a file, instead of stdout...

stdin/stdout is more convenient for pipes, but most such programs do
have -i and -o flags for cases like yours.

> seems to be an implicit assumption that there is a single
> encoding that needs to be determined.

Which is reasonable; they aren't the only input/output, they are the
*standard* input and output.  If they have different encodings, they
aren't really standard.  (I have some sympathy for a more lenient
encoding on stderr.)

> That (IIUC) would not be workable for my problem.
>
>  ./myprog.py -e sjis,sjis [other options...]
>
> is acceptable.  Something like:
>
>  python -C 'sys.stdin=...; sys.stdout=...' myprog.py [other options...]
>
> would not be.

Tastes differ; I actually prefer the second, as more explicit.

> I think that being unable to easily change stream encoding
> before first use is orders of magnitude more important than
> being unable to change them on-the-fly.

Yes, but since we're talking specifically about streams you don't
start, that just makes for fragile code that breaks in the field.

-jJ