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

[Steve D'Aprano]

On Tue, 25 Oct 2016 09:02 pm, BartC 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.

Really, Bart? You're stymied by the change of raw_input() to input() in
Python 3? A programmer of your many years experience and skill can't work
out how to conditionally change "raw_input" to "input" according to the
version of the interpreter running. I don't think so.


>> 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?

This discussion is a red herring, because the OP is talking about
non-blocking input. So "Press enter to continue" is not a good model for
what he had in mind.

But regardless, yes, I'd consider using an existing text UI at this point,
rather than try re-inventing the wheel. Unless I *like* re-inventing the
wheel, or that's what I'm being paid for. If I've got two keys to choose
between, I'll probably have more soon:

Page Up, Page Down, Line Up, Line Down, Backwards, Forwards, Refresh, Quit,
Load File, Reload File ... 

Somebody once said, there's really only three numbers you need care about.
Zero, one and infinity. Zero is easy to handle -- you don't do anything.
One is easy, because there's only one thing to do. But once you have two
things, you might as well be prepared to handle an indefinitely large
number of things, because you're surely going to need to.
 
YMMV.



>> then you probably should use an existing text UI like Curses,
>> or a GUI like wxPython etc, rather than trying to reinvent the wheel
>> badly.
> 
> 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.

*shrug* Then find a more lightweight solution. Tkinter? Something even
lighter?

Maybe there is no such lightweight solution? Then that tells you that nobody
else needed this enough to build a solution. Perhaps you're the first!
Congratulations!

Or perhaps you're looking at the question the wrong way. How many thousands
of man-hours, and deaths, came about because people thought that the only
way to fly was by flapping wings like a bird? Maybe there are other ways to
fly... maybe there are other ways to get a good text UI other than
collecting raw keyboard events.

I don't know. I've never needed this enough to care to investigate. Like I
said, it *seems* like the sort of obvious functionality every programmer
should need all the time, but in 15 years I've never, not once, actually
needs a non-blocking way to check for a keyboard event in a situation where
I wasn't using something like curses or a GUI framework.

YMMV.


[...]
> This gives you the ability to do (2) above. From that, you could do (1)
> (echoing) and go on to build full line-orientated input. But you had
> complete control.
> 
> So, why has it all become so difficult?

Build line oriented input? Why would I do that, when the OS does it?

Okay, sure, if you're programming for some sort of primitive system with no
OS or such a feeble one that it didn't even offer line-oriented text I/O,
then needs must, and you have to do what the OS doesn't provide. But that
sort of low-level I/O is precisely what operating systems are for.





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.