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

[Steve D'Aprano]

On Fri, 28 Oct 2016 12:13 am, BartC wrote:

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


Well of course I am. I don't program my code from bare metal. Nobody with
any sense does that, at least not on a PC. Maybe on embedded systems.

I don't write my own memory management, or my own file system, or my own
process scheduler, or any of the other dozens of things that the OS does
much, much better than anything I can do.

Including line editing.


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

Ah, now we're getting somewhere: I'm starting to get a hint of what this
feature might be useful for. Okay.

Sure, I'll accept that perhaps this feature of non-blocking keyboard input
does have its use-cases. I might even revise my plucked-from-thin-air
figure of 97% down to allow for "text-mode editors, IDEs, file-managers,
games, etc.".

All of those are big, complex applications. Not Microsoft Office big, or
Oracle database big, but still, you need things like windows, dialog boxes,
animation, sprites, etc. If I were writing any of those, I would absolutely
want to start with an existing framework or library that provides things
like windows, menus, icons, and text input widgets. Whether I'm doing a GUI
application or a text-based application, I wouldn't be writing this stuff
from scratch like it was 1973.

And yes, that's "throwing the ball into someone else's court". There's no
shame in that.


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

What discrimination? They're available in text environments too. You just
have to use a good text-based UI library, like curses.


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

When you call (raw_)input(), Python stops processing until the user hits
Enter, at which point it returns whatever they typed.

Earlier, I mistakenly posted a recipe that works similarly: it pauses until
the user hits a key. It *blocks* until the user hits a key, then returns
that key and continues.

A non-blocking function might return None if there is no character in the
input buffer, or that character. I don't know -- I'm not sure how the API
would be designed.

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

*shrug*

Python's a pretty high-level language. Not every low-level feature needs to
be part of the Python language. This sounds like something you would write
in a low-level language like C or Rust, turn it into a extension file, and
call it from Python.

You could always check the source code to the Python debugger. Presumably it
already solves this. There has to be *some* solution. After all, operating
systems, text editors, shells, GUI frameworks, etc. all support this.


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

*shrug* My very first response suggested that many people ask for this
feature, but then after writing code to implement it, they find they don't
actually need it. Maybe I'm wrong. But if this is so useful, outside of
specialist areas, why do so few languages support it?


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

How is the interpreter supposed to know that a, b, c are numbers? What sort
of numbers? 16-bit integers, 80-bit floats, Bignums, complex, Fractions, or
something else?

That's a fairly simple thing for the compiler to do in a language with
static types. It knows that a is a float, b an int, and c another float. So
it can automatically call the appropriate input routines, or conversion
routines, or both.

But in a dynamically typed language, the compiler has no idea what you
expect a, b and c to be. So it returns text, and you can convert it
yourself.


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

Nah, I'm pretty sure that's just a simple issue of whether or not the
compiler knows the type. If it does, then you can say:

x: float;
x = read();

and the compiler can choose the right input routine. Otherwise you have to
do so yourself:

x = read_float();


[...]
>>> 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?!

I didn't say that. I said that print might not work, if you call it from a
cron job. (Or it may -- as I said, I don't remember the details. All I
remember is that cron jobs are run under very restrictive environments.)


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

That's nice, but Python is not an Editor Construction Kit that specialises
in writing editors. It can operate under all sorts of conditions, including
some where no editor is possible because there's no keyboard input.

If this feature is so basic, so popular, and so necessary, why hasn't anyone
written the code to provide it and release it for others to use?




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