[issue15216] Support setting the encoding on a text stream after creation

[Nick Coghlan]

Nick Coghlan added the comment:

Metaclasses and monkeypatching encourage bad API design, too, but we still
provide them because they're essential tools for some use cases. In Python,
the system integrator is always right, and we provide them with power tools
to deal with the cases where reality doesn't want to cooperate with the
nice neat model of the world that we provide by default.

For the standard streams, the problem is that the stream is created
automatically by the interpreter, and sometimes we will get the encoding
choice wrong (because the info we retrieve from the OS doesn't match what
the user actually wants), but rebinding the names to a new IO stream causes
other problems. Now, we have two choices at this point:

1. Assume there is *no other API involving implicit text stream creation in
any third party Python 3 library anywhere* that will ever have this problem
and create a solution that only works with the standard streams

2. Acknowledge that while the implicit way we create the standard streams
is unusual, it is unlikely to be *unique*, so it actually does make sense
to provide the ability to change the encoding of an existing stream as a
general purpose feature fenced about with as many "you probably don't want
to use this unless you really know what you are doing, otherwise it may eat
your data" warnings as seems appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15216>
_______________________________________