Why doesn't Python include non-blocking keyboard input function?

[BartC]

On 25/10/2016 12:25, Chris Angelico wrote:
> On Tue, Oct 25, 2016 at 9:02 PM, BartC <bc at 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