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

[BartC]

[repost as original disappeared]
On 27/10/2016 12:41, Steve D'Aprano wrote:
> On Thu, 27 Oct 2016 09:42 pm, BartC wrote:

> I don't need one character at a time. I want to pause everything else, ask
> the user a question, and wait for them to enter an entire line.
>
> And no, I don't want to reinvent the wheel and build up line editing from
> character editing myself. I don't want to have to handle backspacing and
> navigation myself.

You're just throwing the ball into someone else's court then.

YOU don't want such features to be part of a language, but you expect 
others to be able to write text-mode editors, IDEs, file-managers, games 
etc without them?

Presumably you're OK with those features being available in a GUI 
environment? So why the discrimination?

Text-apps aren't so common now but I get the impression that you would 
never have found this stuff useful.

> Feel free to give an answer. Apart from reinventing the wheel and building
> functionality that Python already supports, what do you use non-blocking
> keyboard input for? Can you give some examples of how you might use it?

I didn't even know what non-blocking meant until this thread.

But suppose you're writing an app such as a debugger, or interpreter, or 
anything that keeps going until interrupted or controlled by some key 
event. If you're executing a billion instructions per second you don't 
want to keep stopping every N instructions to ask the user for any 
special requests, or to press Enter to continue.

Is that good enough?

Doubtless your solution would be some large sledgehammer to crack this 
particular nut.

> How about Lisp? Scheme? Fortran? Java? C#? Objective-C? Dylan? Forth? Well
> I'd completely believe Forth has this, I think you'd like Chuck Moore, I
> think the two of you think in similar ways.
>
> Cobol? Hypertalk? Inform 7? Bash? Haskell?

> There must be *some* language other than your own that offers this feature,
> if it is as obvious, useful, simple and basic and you claim.

I'm not familiar with that many languages. However if you google for 
'<language> non-blocking keyboard' then it seems quite a few people are 
interested in the feature!

>> But I seem to remember in a previous thread that Python had some problem
>> even with line-buffered input. Something to do with only getting a line
>> of input as a string then needed to do some processing to read
>> individual elements, IIRC.
>
> O_o
>
> Um, of course it gets a line of input as a text string. What would you
> expect to get the user's text as? A bitmap?

   print "Enter 3 numbers: "
   readln a,b,c

I'm fairly sure this kind of input was common in plenty of other 
languages. But maybe even that is being frowned on now; /that/ wouldn't 
surprise me either.

>
>> (FWIW my own language does strive to have this basic stuff built it. But
>> getting full keyboard and console handling working as I want it across
>> both Windows and Linux is challenging. It's a bit easier on Windows as,
>> even though you're using a console, you have the full resources of the
>> Win32 API to draw on.
>>
>> On Linux you can't assume any such resources except some apparently
>> 1970s-style terminal handling, from what I can figure out.)
>
> And possibly not even that. If your script is running as a cron job, I
> believe that there's no terminal attached, and possibly no stdin or stdout.
> I don't remember the details.

The same argument as before. So we don't have print() as part of the 
language either before there might not be a stdout?!

The fact is that if I want to run an editor under Linux, I will need a 
display, and a keyboard, and I want to have the means to use them.

-- 
bartc