Remove new pyrepl "warning" on Windows

[terryjreedy]

Bug report

Whenever I start the REPL on Windows, it now prints a new statement: "warning: can't use pyrepl: No module named 'readline'" and as things now, it will continue to do so indefinitely. This is obnoxious. This is not a warning, not something I can or should do anything about (other than switch to Linux), but a statement of fact. Please kill it at least on Windows. And Mac if the situation is the same (never available). It seems useless on *nix too, though I don't care. Just document its availability in appropriate places like we do with other things that are not available everythere.

If desired to make its use obvious, color the splash message in places.

Linked PRs

• gh-118628: Don't display pyrepl warning on Windows #118665

[sobolevn]

I agree, this will cause a lot of confusion among devs.

[eryksun]

Could someone point me to the PEP or discussion for this change?

_pyrepl.simple_interact tries to import _pyrepl.readline and _pyrepl.unix_console, which depend on POSIX-only readline, curses, termios, and fcntl. I see no reason that it should even be distributed in the standard library on Windows. It just ends up calling sys._baserepl(). Currently, the only reason I can see to include the _pyrepl package on Windows is that all of the pager functions were moved there, but they could be moved to a top-level _pager module.

Attempts to use _pyrepl in "Modules/main.c" and "Lib/site.py" should gracefully handle its absence. site can continue to try to import _pyrepl.readline. Maybe _pyrepl could be available on Windows one day. But trying to import _pyrepl.unix_console seems like something that should be encapsulated in the implementation. In "Modules/main.c", it can try pymain_run_module(L"_pyrepl", 0), and fall back on calling sys._baserepl().

[ambv]

Sorry for the rough initial experience, y'all!

Could someone point me to the PEP or discussion for this change?

The issue is #111201, it's still open.

As for "a PEP", this is not an API nor a language feature. This needs a PEP in the same sense that rewriting output of python --help did or changing the output of tracebacks did. The main visible change is multiline editing and a color prompt, and we're not removing the previous REPL at all.

The Steering Council was aware this change was coming and didn’t suggest a PEP before. Of course, if they change their mind, we’ll provide one.

I see no reason that it should even be distributed in the standard library on Windows.

@eryksun, there's plenty of other libraries distributed on Windows that are specific to another platform like asyncio.unix_events, pty, posixpath, shutil.chown, tty, and so on.

Here, we want to remove our reliance on readline and curses during the sprints in Pittsburgh, possibly unblocking Windows support in beta 2. If that won't work, we will make sure the Windows experience is no worse than it was on Python 3.12.

In any case, this is now solved with GH-118665 landed so we can close this.

[eryksun]

Sorry for the rough initial experience, y'all!

Could someone point me to the PEP or discussion for this change?

The issue is #111201, it's still open.

As for "a PEP", this is not an API nor a language feature. This needs a PEP in the same sense that rewriting output of python --help did or changing the output of tracebacks did. The main visible change is multiline editing and a color prompt, and we're not removing the previous REPL at all.

I never said it needed a PEP. I was just looking for the discussion about this change, so I could understand the rational for implementing this in a way that requires distributing and attempting to use the _pyrepl package on Windows, why the pager functions were moved there when paging text in general isn't intrinsically related to a REPL, and what if any development plans there were for Windows in the long-term roadmap.

@there's plenty of other libraries distributed on Windows that are specific to another platform like asyncio.unix_events, pty, posixpath, shutil.chown, tty, and so on.

I've never understood why tty and pty are distributed on Windows since trying to import them immediately fails for lack of termios, and there's pretty much no chance that anyone will ever step up to support the termios module in the standard library on Windows, though I'd love to be proven wrong there. shutil.chown() should only defined if os.chown() exists. Its existence on Windows is a mistake. The asyncio package and posixpath are different. They're both meant to be used on Windows. Trying to import unix_events deliberately fails with a clear message that it's not supported on Windows. This is all a moot point if there's a long-term roadmap to support _pyrepl on Windows.

[hongkilldong]

This problem is still there if you run python via Py_Main on windows platfrom.
I'm running on Windows 11 Pro 23H2 22631.4460.

[terryjreedy]

"Windows 10 TH2 or later required" is a different message message from the one I reported. I have no idea of what win10 TH2 is, but if it is an early version, and the repl requires a feature added later (to color without readline, for instance), the statement would be true and unavoidable.

[hongkilldong]

It' interesting that sys.getwindowsversion() call made in embedded python reported invalid Windows version.

At the same time "normal" python correctly reported Windows version it's running on

That is the main cause why warning mentioned above is reported.
Reading CPython sources didn't give a answer.

[AraHaan]

It' interesting that sys.getwindowsversion() call made in embedded python reported invalid Windows version.

At the same time "normal" python correctly reported Windows version it's running on

That is the main cause why warning mentioned above is reported. Reading CPython sources didn't give a answer.

This is because the assemblies need a value for Windows 10 in the supportedOS section of the Manifest resource in the Resource Sections of the python assemblies including the c extensions to not run in compatibility mode on Windows itself under an older version of Windows. The Windows API in this case will lie to python because of this.

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
    <application> 
      <!-- Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
      <!-- Windows 10 / Windows 11 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
    </application>
  </compatibility>

Some of the contents of the manifest in a nutshell.