On 1/16/21, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > On 17/01/21 12:40 pm, Chris Angelico wrote: >> This is true. However, at some point, the boundary is crossed from >> Python into the C library. Something, at that point, knows. It's very >> common to have a flush option available, so it should be used. > > I'm wondering whether the problem in this particular case stems > from trying to use parts of curses without initialising it > properly. I expect that initialising curses would put stdout > into some kind of unbuffered mode, and the rest of it assumes > that this has been done.
The buffering mode cannot be changed for an in-use stream: "setvbuf() ... may be used only after opening a stream and before any other operations have been performed on it". So it would have to open a new stream, which can only be done legitimately by device or file name via C freopen(). Code that overwrites the FILE record (e.g. *stdout = *stream) is not legitimate and cross-platform. You can force the interpreter to change stdout to unbuffered mode at startup via `-u` or the PYTHONUNBUFFERED environment variable. In Linux, there's also the `stdbuf` command (e.g. stdbuf -o0 python ....), which uses an LD_PRELOAD hook to inject a shared library that calls setvbuf() at process startup. There's no analog to that in Windows for various reasons. -- https://mail.python.org/mailman/listinfo/python-list
