[Python-ideas] changing sys.stdout encoding

Mike Meyer mwm at mired.org
Thu Jun 7 23:00:47 CEST 2012

On Thu, Jun 7, 2012 at 4:48 PM, Rurpy <rurpy at yahoo.com> wrote:
> I suspect the vast majority of
> programmers are interested in a language that allows
> them to *effectively* get done what they need to, whether
> they are working of the latest agile TTD REST server, or
> modifying some legacy text files.

Others have raised the question this begs to have answered: how do
other programming languages deal with wanting to change the encoding
of the standard IO streams? Can you show us how they do things that's
so much easier than what Python does?

> And even were I to accept your argument, Python is
> inconsistent: when I open a file explicitly there is
> only a slight penalty for opening a non-default-encoded
> file (the need the explicitly give an encoding):

The proper encoding for the standard IO streams is generally a
property of the environment, and hence is set in the environment. You
have a use case where that's not the case. The argument is that your
use case isn't common enough to justify changing the standard library.
Can you provide evidence to the contrary? Other languages that make
setting the encoding on the standard streams easy, or applications
outside of those built for your system that have a "--encoding" type

> I wasn't suggesting a change to the core level (if by that
> you mean to the interpreter).  I was asking if some way could
> be provided that is easier and more reliable than googling
> around for a magic incantation) to change the encoding of one
> or more of the already-open-when-my-program-starts sys.std*
> streams.  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.

Why presume that this needs a change in the library? The method is
straightforward, if somewhat ugly. Is there any reason it can't just
be documented, instead of added to the library? Changing the library
would require a similar documentation change.


More information about the Python-ideas mailing list