Tal, I presume you made this initially duplicate branch so you could fiddle around with the code and test on Pipelines without having to revert experiments on the main branch. So I don't need to review this initial copy.

The 5 failures are the same on all 3 systems: Ubuntu, Win32, and Win64. Moreover, the failures were all the same in that they only happen when there is an output line (a None in the sidebar list) between first code lines ('>>>' in the sidebar list). Then on these 3 systems, None was moved up above the first '>>>'. The two tests with no None after '>>>' did not fail.

A quick fix would be to run the simplest test in setUpClass (or before the class) inside try-except to set a flag on the bad systems and use that to skip the 5 failing tests:

Pipelines somehow executes tkinter gui code differently (and seemingly wrongly) from GHA, Travis, and our systems. Does it use different simulator? Steve Dower might know, and we could ask, maybe after narrowing down the difference a bit more.

I will upload a patch for debug prints. The tricky part is that shell intercepts stdout/err (and anything added there breaks tests!). So text must be saved to be printed after shell is destroyed. Initially, I am capturing the content of shell.text. You can adjust to capture, for instance, whatever mark and tagging the sidebar uses to create its list.

On my machine, the text contents, after the boilerplate header, are, for multiline statement,

if True:
	print(1)

	
1

and for single-line statement.

1
1

(The space at top and bottom is the exaggerated interline space, not blank lines)l. The single-line text corresponds to ['>>>', None, '>>>'] in the sidebar, the last prompt being opposite the empty line after the output, waiting for input.
(Tal, I know you know this. The comment is for me and anyone else who reads this ;-).

I believe that our sidebar tests are failing because on Ubuntu and Windows, Pipelines, unlike other test runners, captures sys.stdout for each test method in a way that keep output from reaching shell. The direct evidence is that Pipeline prints the output after the test in verbose mode after failure reports.

test_single_line_command (idlelib.idle_test.test_sidebar.ShellSidebarTest) ... FAIL  # In verbose listing of each test.
Stdout:
1
...
FAIL: test_single_line_command  ...  # In listing of failures.
...
Stdout:
1

The indirect evidence is that it explains all the failure reports with a plausible interpretation. For instance

- [None, '>>>', '>>>']
+ ['>>>', None, '>>>']

for

   |    # Last blank of header, before first prompt.
>>>| 1  # User input, an expression statement.
   | 1  # Echoed output.
>>>|    # Blank link for next input.

My previously statement 'None is moved' was, I believe wrong. The None for the output print is missing when the output is missing. The replacement as the beginning of the fixed length slice is whatever was before the input prompt. In this case it is None. If the previous line were, for instance >>>| a = 1, then I expect that the error report would be
- ['>>>', '>>>', '>>>']. This could be tested. I am not doing so now so you can look at the failure reports if you want.

Possible fixes, other than skipping, to make tests pass.

1. Reinitialize shell for each test.
2. Capture sys.stdin when shell is created and reset sys.stdin in reset_shell.
3. Set use_subprocess to True. (And make that the default in Shell before main is called instead of at the top of main.)

I had already thought that only testing within process was slightly dubious. But I don't know all the implications of using subprocess and sockets in tests, or what special helper might be needed or useful. 2. seem easy and maybe fastest in execution.

I hope tomorrow to do more manual testing and look at how to change indents to spaces. I believe a PR for the latter will not conflict with this one. For a beta release, these are more important than polishing the code.

@terryjreedy, thanks for helping to work on this, and that's some excellent analysis!

You seem to have found the source of the issue with PyShell's setting of sys.stdout apparently being somehow disabled. I've pushed a commit which tries to reset sys.stdout for each test, just to see if that works.

Hurrah, it worked!!!! 🥳

Are we done with this? It seems to have served it purpose.

Are we done with this? It seems to have served it purpose.

Indeed.