This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients benjamin.peterson, gjb1002, gvanrossum, ncoghlan, pitrou, pjenvey, stutzbach, terry.reedy
Date 2016-03-16.13:12:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1458133975.59.0.336970074476.issue13601@psf.upfronthosting.co.za>
In-reply-to
Content
Changing the target version and summarising my understanding of the status quo:

"python3": sys.stderr is line buffered at both the TextIOWrapper layer and may be fully buffered at the binary BufferedWriter layer if the output is redirected to a file
"python3 -u": the BufferedWriter layer is omitted entirely, leaving only the line buffering at the TextIOWrapper layer

Looking at http://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html (which also covers stdout and stderr), it specifically says about stderr: "When opened, the standard error stream is not fully buffered;".

That means either line buffering or no buffering is considered acceptable, but full buffering is not.

So, at the very least, it seems to me that the way we configure stderr should be the same regardless of whether or not "-u" is used: omit the BufferedWriter layer.

Given that POSIX allows compliant implementations to use line-buffering on stderr, the "missing trailing newline and no implicit flush() is ever triggered" scenario is probably obscure enough not to worry about.
History
Date User Action Args
2016-03-16 13:12:55ncoghlansetrecipients: + ncoghlan, gvanrossum, terry.reedy, gjb1002, pitrou, pjenvey, benjamin.peterson, stutzbach
2016-03-16 13:12:55ncoghlansetmessageid: <1458133975.59.0.336970074476.issue13601@psf.upfronthosting.co.za>
2016-03-16 13:12:55ncoghlanlinkissue13601 messages
2016-03-16 13:12:55ncoghlancreate