test_python_legacy_windows_stdio in test_cmd_line isn't actually working

[aisk]

PYTHONLEGACYWINDOWSSTDIO will let Windows use old console IO for stdin and stdout, and sys.stdin.encoding will become cp instead of utf-8.

cpython/Lib/test/test_cmd_line.py

Lines 974 to 978 in 0af61fe

	def test_python_legacy_windows_stdio(self):
	code = "import sys; print(sys.stdin.encoding, sys.stdout.encoding)"
	expected = 'cp'
	rc, out, err = assert_python_ok('-c', code, PYTHONLEGACYWINDOWSSTDIO='1')
	self.assertIn(expected.encode(), out)

In this test, it sets PYTHONLEGACYWINDOWSSTDIO to 1 and creates a new Python process to check if sys.stdin.encoding is cp. However, the new process is created by subprocess.Popen with stdin=PIPE, stdout=PIPE, thus the sys.stdin and sys.stdout will not be console IO, so their encoding is always the current console code page (cp) whether PYTHONLEGACYWINDOWSSTDIO is set or not. So actually nothing has been tested.

Another issue with this test is that it expects the encoding to be cp, but on some non-English locale Windows environments, for example, Simplified Chinese locale, it will be gbk, and the test will fail.

A fix is on the way.

Linked PRs

• gh-133374: Fix test_python_legacy_windows_stdio in test_cmd_line #133375
• gh-133374: fix test_python_legacy_windows_stdio #134080
• [3.14] gh-133374: fix test_python_legacy_windows_stdio (GH-134080) #134314

[chris-eibl]

Another issue with this test is that it expects the encoding to be cp, but on some non-English locale Windows environments, for example, Simplified Chinese locale, it will be gbk, and the test will fail.

Another issue where the gbk encoding breaks a test: #132143