Python 3.2 has some deadly infection
On 6/5/2014 4:21 PM, Marko Rauhamaa wrote:
> Terry Reedy <tjreedy at udel.edu>:
>> On 6/5/2014 5:53 AM, Marko Rauhamaa wrote:
>>> Chris Angelico <rosuav at gmail.com>:
>>>> If the standard streams are so crucial, why are their most obvious
>>>> interfaces insignificant to you?
>>> I want the standard streams to consume and produce bytes.
>> Easy. Read the manual entry for stdxxx. "To write or read binary data
>> from/to the standard streams, use the underlying binary buffer object.
>> For example, to write bytes to stdout, use
> This note from the manual is a bit vague:
> Note that the streams can be replaced with objects (like io.StringIO)
> that do not support the buffer attribute or the detach() method
> "Can be replaced" by who? By the Python developers? By me? By random
> library calls?
Fair question. The Python developers will not fiddle with stdxxx for 3rd
party code on 3rd party systems. We do sometimes *temporarily replace
the streams with StringIO, either directly or via test.support when
testing Python itself or stdlib modules. That is done in Lib/test, and
except for testing StringIO, it is only done as a convenience, not a
To test a binary stream filter, you would have to do something else,
like read from and write to actual files on disk. Otherwise, you seem
unlikely to sabotage yourself, even accidentally.
Random non-stdlib library calls could sabotage you. However, in my
opinion, an imported 3rd party module should never modify std streams,
with one exception. The exception would be a module whose entire purpose
was to put the streams in a known state, as documented, and only if
intentionally asked to.
Having said that, bound methods created (first) should work regardless
of any subsequent manipulation of sys. Here is an experiment, run from
an Idle editor.
sysout = sys.stdout.write
sys.stdout = None
(Of course, subsequent attempts to continue interactively fail. But that
is not your use case.)
Terry Jan Reedy