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 josh.r
Recipients Leo Singer, Marcel H2, bethard, eli.bendersky, evan_, josh.r, markgrandi, moritz, naufraghi, palaviv, paul.j3, r.david.murray, sedrubal, serhiy.storchaka
Date 2019-05-07.16:18:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Serhiy: To be clear, Moritz's patch won't work if stdin/stdout are io.StringIO or the like either, since StringIO lacks a buffer attribute.

Personally, I'm content to:

1. Ignore the closeability of the standard handles; that's not part of this bug, and just introduces more headaches to getting a patch approved (and conceivably breaks back compat if the user *wants* the handle closed even if it's a standard handle). Nothing is made worse by ignoring it after all, just not made better immediately.
2. Ignore the possibility of stdin/stdout without a buffer attribute; it will raise an error, but that's a reasonable response to demanding a binary stream in a scenario where only a text stream is available
3. Not use fileno, as it mostly supports the "anti-close" behavior I dismissed in #1, and has a bunch of pitfalls (e.g. a standard handle rebound to a TextIOWrapper around GzipFile or the like has a fileno attribute, but using it bypasses the compression; basically, you can't consider fileno to be equivalent to the underlying binary stream, because binary streams can be wrapped as well).

I'm going to convert Moritz's proposal to a PR and hope I can get core developer approval for it.
Date User Action Args
2019-05-07 16:18:25josh.rsetrecipients: + josh.r, bethard, naufraghi, r.david.murray, eli.bendersky, paul.j3, serhiy.storchaka, moritz, markgrandi, palaviv, evan_, sedrubal, Marcel H2, Leo Singer
2019-05-07 16:18:25josh.rsetmessageid: <>
2019-05-07 16:18:25josh.rlinkissue14156 messages
2019-05-07 16:18:25josh.rcreate