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 vstinner
Recipients berker.peksag, eryksun, gdr@garethrees.org, ncoghlan, serhiy.storchaka, vstinner
Date 2017-10-12.13:45:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507815945.52.0.213398074469.issue28647@psf.upfronthosting.co.za>
In-reply-to
Content
Serhiy Storchaka:
https://github.com/python/cpython/pull/3961#issuecomment-336136160

"I suggest to continue the discussion on the tracker."

Ok, let's continue here.

"We are fixing the outdated documentation inherited from Python 2. First than keep some statement we should consider what it means in the context of Python 2 and what it means in the context of Python 3."

stdin buffering is a complex thing.

When running the UNIX command "producer | consumer", many users are confused by the buffering on the *producer* side.

When running a program in a TTY, the TTY does line buffering for you, you cannot get immediately a single character (without changing the default TTY configuration).

I don't think that we need to say too much. I just suggest to say "stdin is always buffered". That's all.

See my previous messages for the my definition of "buffered" versus "unbuffered" read.

Note: Today I learned the UNIX "stdbuf" command, useful to configure the stdin, stdout and stderr buffering of C applications using <stdio.h>.
History
Date User Action Args
2017-10-12 13:45:45vstinnersetrecipients: + vstinner, ncoghlan, gdr@garethrees.org, berker.peksag, serhiy.storchaka, eryksun
2017-10-12 13:45:45vstinnersetmessageid: <1507815945.52.0.213398074469.issue28647@psf.upfronthosting.co.za>
2017-10-12 13:45:45vstinnerlinkissue28647 messages
2017-10-12 13:45:45vstinnercreate