Wait for a keypress before continuing?

[Steven D'Aprano]

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
        (x) Save
                       [__OK__]


versus:


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



-- 
Steven