On 6/5/2014 4:21 PM, Marko Rauhamaa wrote:
Terry Reedy <tjre...@udel.edu>:

On 6/5/2014 5:53 AM, Marko Rauhamaa wrote:
Chris Angelico <ros...@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 necessity.

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.

import sys
sysout = sys.stdout.write
sys.stdout = None
sysout('works anyway\n')
works anyway

(Of course, subsequent attempts to continue interactively fail. But that is not your use case.)

Terry Jan Reedy


Reply via email to