Armin Ronacher added the comment: > I would like to know of some situations where you want to write some > code that accesses standard streams as binary *and* don't control the > application setup (i.e. library code rather than application code). It > seems to me that a library should take the binary streams as parameters > rather than force the use of stdin/stdout.
The same situations people wrapped streams before on python 2: * code.py users. Werkzeug's traceback system implements a remote python shell through it. * any system that wants to unittest shell scripts on a high level. * any system that wants to execute arbitrary python code and then capture whatever output it did. This is for instance what I see Sphinx users frequently do (or doctests) In fact, the reasons people wrap sys.stdout/sys.stderr on 2.x are the same reasons why people would do it on 3.x: they have arbitrary code they did not write and they want to capture what it does. Since you do not know if that is binary or text you need a stream object that behaves the same way as the default one. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21364> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
