[Python-ideas] Pythonic buffering in Py3 print()

[Stefan Behnel]

anatoly techtonik, 09.01.2012 13:16:
> On Mon, Jan 9, 2012 at 1:51 PM, Stefan Behnel 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?

Well, it does it if you tell it to. Lacking an explicit request, the rest
is platform specific, as usual with multi-level output buffering.

Actually, print() is often the first place where new users get in touch
with I/O "specialties" such as flush() and buffering/queuing, and it's
helpful to learn about them. Not only in the context of terminal I/O but
also for disk or network I/O.


> 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?

All I'm saying is that there is no "right" way to do it, so choosing to
flush implicitly will a) break user code and b) keep some (or many?) users
from getting the behaviour they want. And that without good reason and
without making it "better" or "more correct" through such a change.


>> 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

... or maybe not ...

> and enabling flushing by default will make
> it more pythonic by making code more beautiful (which is better than ugly).

print() is just one way of pushing output "somewhere", and often not the
best one. It's helpful for debugging and mostly acceptable in short
scripts, but it's otherwise useless for most applications. That being said,
I certainly don't claim to have an idea of what "most" users use print()
for and what behaviour "most" users expect...

Stefan