Wait for a keypress before continuing?
steve+comp.lang.python at pearwood.info
Wed Aug 17 20:29:30 CEST 2011
Terry Reedy wrote:
> The difference is between "Hit <enter> to continue" (which we can do in
> portable Python) versus "Hit any key to continue" (which we cannot, and
> which also leads to the joke about people searching for the 'any' key
> ;-). The equivalent contrast for GUIs is "Click OK to continue" versus
> "Click anywhere to continue" If having to click a specific area is okay
> for GUIs, having to hit a specific key for TUIs should be also.
Poor analogy. A better analogy to a GUI would be comparing:
What would you like to do? Select an option and then click OK:
( ) Cancel
( ) Print
What would you like to do?
[__Cancel__] [__Print__] [__Save__]
Actually, a better analogy would be a GUI that made you do this:
What would you like to do? Type the first letter of the option
you prefer in the text field, then click the OK button:
Options: Cancel | Print | Save
My option: [ ............ ] [__OK__]
(ASCII art best viewed with a fixed-width font.)
Generally speaking, the second UI would be preferred.
The raw_input/input UI is well-designed for entering plain text data. It is
extremely poor as a command interface.
Bringing it back to text interfaces, it would be useful to have a text
interface such that commands can be executed using a single key press. You
might want to detect and respond to (say) the arrow keys, or ESC, or P
rather than P<enter>. Curses apps can do it, proof that even under Unix it
is desirable. (Imagine how awkward it would be to use a TUI mail client or
text editor where the only user input was from something like raw_input.)
Unfortunately curses is quite heavyweight for a simple CLI script.
I note also that even the Python interactive interpreter under Linux has an
extremely limited detect-single-keypress capability: Ctrl-C generates a
KeyboardInterrupt without needing to hit Enter, and Ctrl-D exits the
More information about the Python-list