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 -- http://mail.python.org/mailman/listinfo/python-list