On 25/10/2016 12:25, Chris Angelico wrote:
On Tue, Oct 25, 2016 at 9:02 PM, BartC <b...@freeuk.com> wrote:
raw_input('Press the Enter key to continue... ')
Which doesn't work on Python 3. So even here, making it easy by using
line-input, it's not so straightforward.
So you use input() instead. Big deal. The concept is still the same.
If you are doing something more complex, waiting on different keys to do
different things,
You mean, something as sophisticated as press Enter to continue, or Escape
to quit? Or Page Up and Page Down?
Enter to continue or Ctrl-C to quit. Just as easy.
Ctrl-C is not the same; that will just abort (without doing proper
termination such as saving your data, or even just asking the user to
confirm).
But why the need to have to use someone else's massive great wheel? Both
Curses and wxPython are completely over the top IMO for something so
fundamental.
Fundamental? What exactly is fundamental about key-based input? Much
more fundamental is character-based input, where you request *text*
from the user. How often do you care whether someone pressed '1' on
the top row as compared to '1' on the numeric keypad?
I don't think I've made that distinction.
A very basic model of an interactive text-based computer has input at
one end and output at the other. And a keyboard is the obvious choice
for input (a bit easier than voice and less crude than punched cards or
tape).
You can do a lot of stuff with line-based input, but how do you think
/that/ gets implemented? At some point it needs to be a character at a
time or a key at a time; the requirement is there.
Take away a keyboard, real or virtual, from a development computer (or
even one used to check your bank account or go on forums), and see how
far you get.
Much more commonly, you simply ask for
input from the user, and get back a line of text. The user might have
edited that line before submitting it, and that's a feature, not a
bug.
Yeah, 'kill dwarf with axe' and such. It works but it's limited.
Try and write a program where the keys represent the notes on a piano,
and pressing each key plays the corresponding note from speaker.
Having to press Enter after each one is going to cramp your style a bit!
And don't tell me this is advanced because I was doing stuff like this
decades ago. (Of course now I wouldn't have a clue how to make it
generate sounds.)
When you want more flexibility than "Enter to continue or Ctrl-C to
abort", it probably *is* time to get curses or a GUI toolkit, because
you're doing something that's fundamentally different from "request
text from the user".
My IDE and editor that I use every day are based on 'getchx()', an
extended version of getch(). Although it is implemented on top of Win32
which is a kind of complex GUI. (getchx returns key and shift-state
information as well as character codes.)
But the point is, it is just the one function; how it's implemented is
not relevant. It's the kind of function that it would be nice to have
/as standard/ in any language without being told that being able to deal
with key-at-a-time input is an advanced topic!
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
