I found a stackoverflow question (and my then answer) about the same issue:
https://stackoverflow.com/questions/50108354/python-idle-running-code-differently-than-other-ides

Although the code posted does not run, it gives a very legitimate use case (<Enter> is the signal) in which stream mixing is the lesser evil compared to the clearly wrong blocking of the output needed to decide when to give the signal. I now agree we should fix blocking now, if possible.

Tal, I posted my observations partly in the hope that you might be able to extend them.  So please take a look.

I am thinking about how to test a fix.  Test code needs to be able to 1. send code to be executed by run.py, 2. send a response to input() calls in the code, and 3. retrieve all output from the code.  New test machinery, needed not just for this issue, should be a separate issue.

A possibility including the minimum of transport machinery would be to replace the StdInputFile and StdOutputFile in run.py with test classes giving the needed test access.  Without knowing where the block is, it is unclear how much of the run machinery has to be included.

Another possibility, including all of the transport machinery except for the gui display, would be a test interpreter connected to an unaltered run process through a socket, as usual.  pyshell.PyShell (the shell window itself) initializespyshell.ModifiedInterpreter with itself.  A no-gui TestShell could do the same.  The TestShell would also need TestIn/OutputFile replacements.