Remove new pyrepl "warning" on Windows about cpython

[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]

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().

[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.

[sobolevn]

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