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

[BartC]

On 25/10/2016 22:57, Chris Angelico wrote:
> On Wed, Oct 26, 2016 at 8:24 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>
>> Thankfully, you don't need to run your program from a terminal. You can
>> interpret keyboard events any way you want if your program is an X11 or
>> Wayland client, and forget all about TTYs, baud rates, parity bits,
>> hangups etc.
>
> That still doesn't answer the fundamental question:
>
> Are you looking for KEYBOARD input or TEXT input?

Does it matter that much?

Because even if you opt for TEXT, the input (when interactive which is 
what we're talking about) is usually chopped up into LINE events. What's 
the difference if we want to concentrate on CHAR or KEY events instead?

I've used enough line-buffered editors on teletypes and serial VDUs to 
remember them as horrible to use. Was the input considered TEXT or 
KEYBOARD? I can't remember but it wasn't really important.

And no one has the answered the question of how Curses or a GUI solves 
the problem of getting char or key events. Same machine, same OS, same 
keyboard, but one piece of software has apparently discovered the secret 
which is then denied to other software.

> Until you figure that out, nothing matters. Personally, I'd much
> rather work with text than with actual keys; in the uncommon case
> where I want a keystroke to trigger an action, I'm always working in a
> GUI already, and I can create a menu item with an accelerator. A
> visible one.

Some people want to work at low level, without needing to drag in a GUI, 
and want to do something as simple as finding out if a button has been 
pressed on a standard peripheral that nearly every computer has. It 
can't be that hard!

> Just because you *can* poll the keyboard for events, don't think that
> you *should*.

With my rare forays into GUI, that's exactly what I end up doing: in a 
loop waiting for events.

-- 
Bartc