[Python-ideas] changing sys.stdout encoding
Stephen J. Turnbull
stephen at xemacs.org
Fri Jun 8 13:11:56 CEST 2012
> 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
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).
More information about the Python-ideas