gh-145035: Allows removing the _pyrepl module to completely disable the modern REPL#145159
gh-145035: Allows removing the _pyrepl module to completely disable the modern REPL#145159ambv merged 5 commits intopython:mainfrom
Conversation
…able the modern REPL.
|
Running as a draft to see/fix CI first. I had 100% pass on Windows, then accidentally reverted all my changes, and I haven't tested on Linux yet. |
|
First try |
Reverting my little hack for hiding the module and will un-draft.|
@pablogsal Any concerns about this PR? (FWIW, I'll be maintaining the patch in my fork/backports anyway, this is just to make my[/my successor's] life easier by having the support in |
FFY00
left a comment
There was a problem hiding this comment.
From what I can tell, this implementation seems okay to me. The only thing I could maybe suggest, is that it could make sense to move all the alternative necessary bits — such as the pager implementations — to a built-in module, providing the basic functionality. Though, I really have no strong feelings towards it.
That said, I believe this is a very welcome UX improvement, especially bundled with the other small UX improvements around initialization in 3.15.
Yeah, I considered this, but the refactoring started getting more invasive (plus it was only recently refactored in order to better support pyrepl, and I'm not trying to undo the new repl, just make things not break when it's missing). |
This is an unsupported configuration, but still desirable for some distributions. It also ensures we can continue to keep ctypes as an optional module.
_pyreplmodule #145035