> In Python 2 "print 'something', statement calls were unbuffered and
> immediately appeared on screen.
> In Python 3 "print('something', end='')" calls are buffered. This breaks
> progress bars and other stuff.
>
> 1. What is more "Pythonic" and why?

I find the Py3 behaviour more pythonic: flushing should be explicit (which
is better than implicit). The mere fact that the user did *not* provide a
terminator shows that there are likely other things to follow.

Do you find pythonic that `print` statement should output string to the screen (according to docs), but it doesn't do this?
">

(original) (raw)

On Mon, Jan 9, 2012 at 1:51 PM, Stefan Behnel <stefan\_ml@behnel.de> wrote:

anatoly techtonik, 09.01.2012 11:30:

> In Python 2 "print 'something', statement calls were unbuffered and
\> immediately appeared on screen.
\> In Python 3 "print('something', end='')" calls are buffered. This breaks
\> progress bars and other stuff.
\>
\> 1\. What is more "Pythonic" and why?

I find the Py3 behaviour more pythonic: flushing should be explicit (which
is better than implicit). The mere fact that the user did \*not\* provide a
terminator shows that there are likely other things to follow.

Do you find pythonic that \`print\` statement should output string to the screen (according to docs), but it doesn't do this?
Do you find ability to stack chars into screen buffer before the output (instead of doing stacking to a string) more important than hiding the low level output implementation details from the users?

A progress
bar is just one specific case where flushing is actually desired. In other
cases, it may not be desired and would rather lead to performance issues.
Making it implicit if a flush happens or not prevents users from
controlling it.

Can you give some examples of these 'other cases'? Maybe 95% of users are using print for progress bars, and enabling flushing by default will make it more pythonic by making code more beautiful (which is better than ugly).