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 roger.serwy
Recipients roger.serwy, terry.reedy
Date 2021-11-14.17:40:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1636911625.9.0.412598043067.issue45804@roundup.psfhosted.org>
In-reply-to
Content
All good questions, Terry! I do have a git clone of the cpython repo, but I haven't worked through the new commit/patch process since Mercurial. I'm a bit rusty.

The buffering provided is for calls to `write`. It does not do any line buffering. Calls to `isatty` will behave the same. The negative side effect is that the subprocess will proceed as if writes have been committed to the PyShell window, so any pending transfers can be lost if the subprocess terminates unexpectedly.

I used a separate OS thread to handle the transfer of the writes rather than using the Tcl/Tk event loop. The Tcl/Tk loop runs on the main thread, so any long-running processes will prevent a `.after` callback function from being called.

The base class was not changed. I haven't followed all the changes to the stream class (and its implications) since 3.5, so the code subclasses the newer `StdOutputFile` class to minimize disruption.
History
Date User Action Args
2021-11-14 17:40:25roger.serwysetrecipients: + roger.serwy, terry.reedy
2021-11-14 17:40:25roger.serwysetmessageid: <1636911625.9.0.412598043067.issue45804@roundup.psfhosted.org>
2021-11-14 17:40:25roger.serwylinkissue45804 messages
2021-11-14 17:40:25roger.serwycreate