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 martin.panter
Recipients Albert.Zeyer, Drekin, martin.panter
Date 2015-08-04.04:30:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Results of experimenting on 3.6:

* The startup messages are written to standard error.
* The interactive interpreter prompts to the original standard error if Readline not used. But with Gnu Readline, prompts do go to the original standard output, as does other interactive Readline output (echoed input etc). This is what Albert reported.
* The interactive interpreter always reads from the original standard input, whether Readline is used or not.
* The displayhook() function always writes to the current sys.stdout, as documented.
* The excepthook() function always writes to the current sys.stderr, also as documented.
* The input() function is documented to prompt to sys.stdout, however see Issue 1927 for some quirks with that.
* The input() function always reads from the current sys.stdin. The Readline library is only used if sys.stdin and sys.stdout are the original file descriptors.

I agree it would probably be more consistent for the interpreter prompt to go to standard output. It looks like stdout is inspected to determine whether Readline will be used, while stderr is not inspected. So it makes sense for the prompt to go to stdout.

However I disagree that it should go to a redirected stream, sys.stderr or sys.stdout, since sys.stdin does not affect input. But see Issue 17620, about redirecting sys.stdin.
Date User Action Args
2015-08-04 04:30:06martin.pantersetrecipients: + martin.panter, Albert.Zeyer, Drekin
2015-08-04 04:30:06martin.pantersetmessageid: <>
2015-08-04 04:30:06martin.panterlinkissue12869 messages
2015-08-04 04:30:06martin.pantercreate