New submission from Martijn Pieters: Run `python3.3 -h` and the `-u` option is documented as:
> -u : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x > see man page for details on internal buffering relating to '-u' Note that only `stdout` and `stderr` are mentioned. The online documentation at http://docs.python.org/3/using/cmdline.html#cmdoption-u doesn't agree: > ... the binary layer of the stdin, stdout and stderr streams ... nor does `man python3.3`, which claims: > -u Force the binary I/O layers of stdin, stdout and stderr to be > unbuffered. The text I/O layer will still > be line-buffered. So, is `stdin` going to be unbuffered, or not, when using `-u`? Running a simple test shows that `stdin` is firmly being buffered regardless of the `-u` switch: $ python3.3 -c 'import sys; print(sys.stdin.buffer, sys.stdout.buffer)' <_io.BufferedReader name='<stdin>'> <_io.BufferedWriter name='<stdout>'> $ python3.3 -u -c 'import sys; print(sys.stdin.buffer, sys.stdout.buffer)' <_io.BufferedReader name='<stdin>'> <_io.FileIO name='<stdout>' mode='wb'> I'll presume here that `stdin` is deliberately buffered, regardless, and that the documentation and man page are out of date here (in python 2, `-u` does include `stdin`). ---------- assignee: docs@python components: Documentation messages: 179718 nosy: docs@python, mjpieters priority: normal severity: normal status: open title: -u (unbuffered I/O) command line option documentation mismatch for sys.stdin versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16937> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com