-
-
Notifications
You must be signed in to change notification settings - Fork 32k
gh-119896: Fix repl ctrl-z on Windows #122217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Is the design of the original REPL that required an Enter after a CTRL-Z actually desirable to repeat? I always found that clunky about the original REPL. IPython on Windows doesn't even implement ^Z handling. (Sure, it doesn't crash with missing SIGSTOP but it complains about an "invalid non-prinatble character U+001A"). ptpython on Windows ignores ^Z entirely. Even Windows' own terminal applications don't agree on the behavior of CTRL-Z. cmd.exe behaves like Python's old REPL, while PowerShell uses CTRL-Z for backspace. I would vote for ^Z to exit immediately, just as ^D does. |
@zooba, what's your take? |
@@ -52,7 +54,10 @@ def disp_str(buffer: str) -> tuple[str, list[int]]: | |||
b: list[int] = [] | |||
s: list[str] = [] | |||
for c in buffer: | |||
if ord(c) < 128: | |||
if c == '\x1a': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to put '\x1a'
in a constant like CTRL_Z
so it's obvious what it represents?
I think it's even more inconsistent than that :) For what it's worth for me Ctrl-Z just adds the "^Z" character as an input in both cmd and powershell, and in cmd that seems to be ignored, while in powershell that seems to be inputted as a character similar to Python when it's not at the beginning of the line. But I'm also on Windows 10.
The main reason why I tried to preserve the behavior is that I'm a little bit loathe to mess with peoples muscle memory. If people do want a less clunky way they've actually still got it - Ctrl-D and it's consistent across operation systems! :) Maybe a lesser concern is if someone coming from Linux is on Windows and hits Ctrl-Z w/o thinking and it immediately exits. That's a lot less recoverable than it is on Linux/Mac. But we could just go with the patch @devdanzin offered in the issue if there's a strong desire to change the behavior. |
You convinced me. |
…onGH-122217) (cherry picked from commit d1a1bca) Co-authored-by: Dino Viehland <dinoviehland@meta.com>
GH-122451 is a backport of this pull request to the 3.13 branch. |
Please, please, please add refs (such as Working with this later is hard. Please. |
Fixes Ctrl-Z to behave like the existing Windows REPL:
Basically we get the ability to output the '\x1a' character as
^Z
(knowing it has a length of 2) and we account for it's length in the output. To get the ability to quit we register a new command like "exit" or "quit". Finally we no longer register the keyboard shortcut on Windows.More of this could be wrapped up in sys.platform checks for win32, but I don't think they're strictly necessary - Ctrl-Z will just immediately do a suspend on Linux and will never be in the input.
We could extend this to more Ctrl-characters (e.g. you can type "Ctrl-E" and get
^E
in the input and there's many more that don't map to useful control keys) but I'm not sure it has any value. We could also drop making Ctrl-D exit the process on Windows but I suspect this is a general usability improvement for people working on both platforms.