On Fri, 13 Jan 2012 17:00:57 +0100
Xavier Morel <python-dev@masklinn.net> wrote:
> FWIW this is not restricted to Linux (the same behavior change can
> be observed in OSX), and the script is overly complex you can expose
> the change with 3 lines
>
>     import sys
>     sys.stdout.write('promt>')
>     sys.stdin.read(1)
>
> Python 2 displays "prompt" and terminates execution on [Return],
> Python 3 does not display anything until [Return] is pressed.
>
> Interestingly, the `-u` option is not sufficient to make
> "prompt>" appear in Python 3, the stream has to be flushed
> explicitly unless the input is ~16k characters (I guess that's
> an internal buffer size of some sort)

"-u" forces line-buffering mode for stdout/stderr, which is already the
default if they are wired to an interactive device (isattr() returning
True).

But this was already rehashed on python-ideas and the bug tracker, and
apparently Anatoly thought it would be a good idea to post on a third
medium. Sigh.

If you track this more closely, you'll notice there are four issues (surprises) from the user point of view:1. print() buffers output on Python3">

(original) (raw)

On Fri, Jan 13, 2012 at 7:19 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 13 Jan 2012 17:00:57 +0100
Xavier Morel <python-dev@masklinn.net> wrote:
> FWIW this is not restricted to Linux (the same behavior change can
> be observed in OSX), and the script is overly complex you can expose
> the change with 3 lines
>
> import sys
> sys.stdout.write('promt>')
> sys.stdin.read(1)
>
> Python 2 displays "prompt" and terminates execution on \[Return\],
> Python 3 does not display anything until \[Return\] is pressed.
>
> Interestingly, the \`-u\` option is not sufficient to make
> "prompt>" appear in Python 3, the stream has to be flushed
> explicitly unless the input is \~16k characters (I guess that's
> an internal buffer size of some sort)

"-u" forces line-buffering mode for stdout/stderr, which is already the
default if they are wired to an interactive device (isattr() returning
True).

But this was already rehashed on python-ideas and the bug tracker, and
apparently Anatoly thought it would be a good idea to post on a third
medium. Sigh.

If you track this more closely, you'll notice there are four issues (surprises) from the user point of view:
1\. print() buffers output on Python3
2\. print() also buffers output on Python2, but only on Linux
3\. there is some useless '-u' command line parameter
(useless, because the last thing user wants is not only care about Python 2/3, but also how to invoke them)
4\. print() is not guilty - it is sys.stdout.write() that buffers output

1-2 discussion was about idea to make new print() function behavior more 'pythonic', i.e. 'user-friendly' or just KISS, which resulted in adding a flush parameter
3 is a just a side FYI remark
4 doesn't relate to python-ideas anymore about fixing print() - it is about the \*cause\* of the problem with print() UX, which is underlying sys.stdout.write() behavior

I asked 4 here, because it is the more appropriate place not only to ask if it can be/will be fixed, but also why. The target audience of the question are developers.

Hope that helps Antoine recover from the sorrow. ;)
--
anatoly t.