Repository navigation
gh-145035: Allows removing the _pyrepl module to completely disable the modern REPL - #145159
ambv merged 5 commits into
Conversation
Sorry, something went wrong.
…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. |
Sorry, something went wrong.
|
First try |
Reverting my little hack for hiding the module and will un-draft.
Sorry, something went wrong.
|
@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 main as well.) |
Sorry, something went wrong.
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.
Sorry, something went wrong.
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). |
Sorry, something went wrong.
…able the modern REPL (pythonGH-145159)
This is an unsupported configuration, but still desirable for some distributions. It also ensures we can continue to keep ctypes as an optional module.