> If you dropped the isatty() check for stdout in Linux, you may 
> end up with the output of Readline in the file (assuming
> Readline is okay with this). The file would include all the
> cursor positioning codes, backspaces, etc, that Readline
> generates. But I haven’t actually tried this.

Yes, that's what happens. 

It seems to me the isatty check could be moved to call_readline in Modules/readline.c. This way PyOS_ReadlineFunctionPointer decides whether to call PyOS_StdioReadline. (See issue 512981 for the patch that introduced the isatty check.)

A related issue in Windows is that when stdout isn't a console, the text encoding defaults to the locale's ANSI encoding (e.g. cp1252). UTF-8 can be forced by setting the environment variable PYTHONIOENCODING=utf-8.

Also of concern is the pyreadline module. Its [Console class] assumes that the process standard handles are console handles. This is generally valid given the isatty check. OTOH, when I removed this check and redirected stdout to a file, pyreadline crashed in an endless loop. 

pyreadline's hook could punt to PyOS_StdioReadline if stdin and stdout don't both refer to the console. The problem there is calling the CRT's _fileno (POSIX) function in Python. Maybe the os module could wrap fileno in Modules/posixmodule.c. In addition to accepting a FILE pointer, os.fileno could accept an enum of C_STDIN, C_STDOUT, and C_STDERR.

[1]: https://github.com/pyreadline/pyreadline/blob/0be3f019ecfdaf740555dc91a1156ddd5dd195f2/pyreadline/console/console.py#L176