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

[BartC]

On 26/10/2016 02:02, Steve D'Aprano wrote:
> 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.

I could probably figure it out. But how about a beginner?

(When I post Python code I try and make sure it works on both, or 
specify which version.)

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

Can tkinter do it without creating a distracting pop-up window at the 
same time? If not then that's too intrusive.

Curses? If I try 'import curses' (on Windows), I get 'No module named 
'_curses'. Same with ncurses or Curses. Now instead of getting on with 
it I have to go chasing some add-on. And if I want to share a bit of 
code with someone else, then /they/ have to do the same!

My point is that this simple stuff just be included in a language.

> Maybe there is no such lightweight solution? Then that tells you that nobody
> else needed this enough to build a solution.

I find this a lot with stuff that originates on Unix or Linux.

(Do you know when I create executables that run on Linux, I have to try 
and cram all the support files within the executable itself - because it 
appears to be impossible to discover the path the executable was started 
from. With a view to using the same or adjoining path for associated 
files. When I ask about this, Oh it's never been needed!

Same with basic keyboard stuff that any microcomputer from the 80s could 
do in an instant.)

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

By non-blocking you mean checking if a key has been pressed rather than 
waiting for it to be pressed? I use the latter ALL THE TIME when 
debugging. The former less often, because if I wanted to use it to abort 
huge amounts of output, I just abort the program (with Ctrl Break).

Nevertheless, it is still used sometimes, and it's there when I need it 
(NOT Python):

repeat
     print "A"
until testkey()

>> So, why has it all become so difficult?
>
> Build line oriented input? Why would I do that, when the OS does it?

Sometimes you want your own line-input functions because they need to be 
customised to do special things. Assign special meanings to certain key 
events for example.

You make it sound completely crazy like building your own OS. But I've 
done this dozens of times (and yes including when there /was/ no OS), it 
really isn't a big deal. Except when a language strives to make it so.

 > I don't know. I've never needed this enough to care to investigate.

Try this little task. In the late 70s I was fascinated by the ability of 
a teletype to do this: it would ask a Yes/No question, perhaps:

    .CONFIRM (YES/NO):

But then, instead of typing YES<return> or NO<return>, if either Y or N 
was pressed, it would auto-complete it, printing 'ES' or 'O' and doing a 
Return for you ("." is the prompt; you have to imagine the clatter):

    .CONFIRM (YES/NO): YES
    .

How hard is it to do this nearly 40 years On a machines a million times 
more powerful? And in Python (although I'd imagine any difficulties it 
has originate outside the language and probably affect others).


Bartc