[Python-ideas] changing sys.stdout encoding

[Stephen J. Turnbull]

Rurpy writes:

 > Python is inconsistent:

Yup, and I said there is support for dealing with that inconsistency.
At least I'm +1 and Nick's +0.5.

So let's talk about what to do about it.  Nick has a pretty good
channel on the BFDL, and since he doesn't seem to like an addition to
the stdlib here, it may not go far.  But I don't see a reason to rule
out stdlib changes yet.

As far as I'm concerned, there are three reasonable proposals:

 > > [S]ince a 3-line function can do the job, it might make just as
 > > much sense to put up a package on PyPI.

 > I hardly think it is worth the effort, for either the producer 
 > or consumers, of putting a 3-line function on PyPI.  Nor would 
 > such a solution address the discoverability and ease-of-use 
 > problems I am complaining about.

Agreed that it's pretty weak, but it's not clear that other solutions
will be much better in practice.  Discoverability depends on
documentation, which can be written and improved.

I think "ease of use" is way off-target.

 > I presume that would be a standard library change (in either the io
 > or sys modules) and offered a .set_encoding() method as a
 > placeholder for discussion.

Changing the stdlib is not a panacea.  In particular, it can't be
applied to older Pythons.  I'm also not convinced (cf. Nick's post)
that there's enough value-added and a good name for the restricted
functionality we know we can provide.

 > An inferior and bare minimum way to address this would be to at
 > least add a note about how to change the encoding to the sys.std*
 > documentation.  That encourages cargo-cult programming and doesn't
 > address the WTF effect but it is at least better than the current
 > state of affairs.

IMO, this may be the best, but again I doubt it can be added to older
versions.

As for the "cargo cult" and "WTF" issues, I have little sympathy for
either.  The real WTF problem is that multi-encoding environments are
inherently complex and irregular (ie, a WTF waiting to happen), and
Python can't fix that.  It's very unlikely that typical programmers
will bother to understand what happens "under the hood" of a stdlib
function/method, so that is no better than cargo-cult programming (and
cargo-cult at least has the advantage that what is being done is
explicit, allowing programmers who understand textio but not encodings
to figure out what's happening).