[Python-ideas] changing sys.stdout encoding
rurpy at yahoo.com
Thu Jun 7 04:34:05 CEST 2012
On 06/06/2012 02:39 AM, Stephen J. Turnbull wrote:
> Rurpy writes:
> > But even if not, I'm sorry, compared with running a single
> > command with an encoding option, I think messing with
> > environment variables is not really a workable solution.
> You have a workable 2-line solution, which you posted.'
Please don't misunderstand why I posted... as you say,
my code now works fine and I understand how to handle
this problem when I encounter it in the future.
I took the time to post here because it took an inordinate
amount of effort to find a solution to a legitimate need
(your opinion to the contrary not withstanding) and the
resulting code which should have been trivially simple
and obvious, wasn't.
It is a minor issue but the end result of experiences
like this, although infrequent, is often "WTF, why is
this simple and reasonable thing so hard to do?". And
after a few times some programmers will start to wonder
if maybe Python is not really an industrial-strength
language -- one that they can be effective all the time,
even when the problem falls outside the 95% demographic.
(And I am not talking about things totally out of
python's scope like high performance computing or
> It's ugly and
> hard to find, and it should be, to discourage people from thinking
> it's something they might *want* to do. But they shouldn't; people in
> multilingual environments should be using UTF-8 externally unless they
> have really really special needs (and even then they should probably
> be using UTF-8 embedded in markup that serves those needs).
I wanted to do it because it was the correct design choice.
The suggestion that to redesign an entire existing technical
and personnel infrastructure to use utf-8, is a better
choice is, well, never mind.
It is not the place of language designers to intentionally
make it hard to solve legitimate problems. There *are*
other encodings in the world, there will be for sometime
to come, and some programmers will sometimes have to deal
with that. Non-utf-8 encodings are not so evil (except in
the minds of some zealots) that working with them conveniently
should be made difficult. (I am reminded of the Unix zealots
of days past who refused to deal with Windows line endings.)
The way I chose to deal with the encoding requirements I
had was the correct way. It's unfortunate that Python
makes it uglier than it should be.
The discussion seems to be going off topic for this list.
I understand there is no support here for providing a non-
obscure, programmatic way of changing the encoding of the
standard streams at program startup and that's fine, it
was a suggestion.
Thank you all for the feedback.
More information about the Python-ideas