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

[Steve D'Aprano]

On Thu, 27 Oct 2016 09:42 pm, BartC wrote:

> On 27/10/2016 07:51, Steven D'Aprano wrote:
>> On Thursday 27 October 2016 12:12, BartC wrote:
>>
>>> I don't
>>> understand the argument that a language shouldn't have a basic keyboard
>>> API because some computers it could run on might not have a keyboards.
>>
>> That's not the argument. The argument is that Python has a basic keyboard
>> API: raw_input (in Python 2) or input (in 3).
>>
>> This supports 97% of keyboard-based interaction, namely blocking
>> line-based text input. Ctrl-C (KeyboardInterrupt) can be co-opted to
>> support maybe another one or two percent.
>>
>> The question is, what are the use-cases for the sorts of key APIs you are
>> asking for? Who needs them? Why should it be a language feature?
> 
> If a language (or more likely an OS such as Unix) doesn't natively
> provide a certain feature, then it's not surprising that 97% of
> applications don't use it!

Perhaps you should read my statement again.

My claim (plucked from thin air, of course, but nevertheless I'm sticking by
it) is that for 97% of use-cases, when a non-GUI program needs text input
from the user, the *right solution* is blocking line-based text input.

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.



>> Those are not rhetoricial questions.

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?


>> Python falls neatly into the same niche of languages as (for example)
>> Ruby, Javascript, Lua, Swift, Tcl, and (not quite as well) bash, Java,
>> Julia. Which of these languages offer non-blocking keyboard input as a
>> standard part of the language?
> 
> That doesn't surprise me either. 

That was a question, not a statement.

You claim that this sort of low-level non-blocking keyboard input is
a "basic" API. Okay, then which other languages offer this?

If Python is the odd one out, if every other programming language bar Python
provides this API, then I'll cheerfully acknowledge that I'm terribly
wrong. I don't understand what this function is good for myself, but
obviously thousands of others do, so I'll learn something from them.

Or... if no other language offers this "basic" API, then maybe its not that
useful or simple, and perhaps not that basic.


> Even implementation languages such as C 
> tend to shy away from the issue. And since C was intimately associated
> with Unix, it starts to get even less surprising!

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.



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


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





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