On Mar 22, 2011, at 7:57 AM, anatoly techtonik wrote: > For example, now I need to remember that on Windows I need to flush > output every time when I want the result of print() with end!='\n' to > appear on the screen immediately. And for the most of my legacy > scripts I used end='\n' when I want to output some progress to user. I > am surprised to know this never worked on Linux, but what I really > didn't expect is to see that choice is made not in user's favor, but > in a favor of speed. This way we'll be writing in a cross-platform > assembly language named 'Python' soon. =) > http://bugs.python.org/issue11633
Yes, on linux, the C library sets up stderr to be unbuffered and stdout to be fully buffered unless it points to a terminal, in which case it's line buffered. (Of course that can always be overridden using setvbuf.) So, yes, your program never worked on linux. If you'd sent the progress messages to stderr, it should've always worked, however. This is partially specified by POSIX (it leaves leeway up to the implementor to choose line buffered or unbuffered when fully buffered isn't called for): > At program start-up, three streams are predefined and need not be opened > explicitly: standard input (for reading conventional input), standard output > (for writing conventional output), and standard error (for writing diagnostic > output). When opened, the standard error stream is not fully buffered; the > standard input and standard output streams are fully buffered if and only if > the stream can be determined not to refer to an interactive device. James _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
