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

[BartC]

On 29/10/2016 17:27, Dennis Lee Bieber wrote:
> On Sat, 29 Oct 2016 15:32:16 +0100, BartC <bc at freeuk.com> declaimed the
> following:
>
>
>> I still think a beginner would much prefer something along the lines of
>> 'readln a,b,c' (and I still think that's more intuitive).
>>
> 	Then I would suggest using something like REXX or a K&K-based BASIC (I
> have no idea, of the top of my head, what Visual BASIC uses).
>
> 	In REXX, everything is considered a string until it needs to be a
> numeric type. And old BASIC would require one to put a data type code on
> the variable name which would control the input parsing.
>
> -=-=-=-=-
> /* */
> say "Enter three integers"
>
> parse pull a b c

That could be workable if it was line-oriented. I strongly suspect it 
isn't, because C isn't, and C seems to have lot of influence.

(Non-line-oriented would mean it just keeps sitting there until it's 
read three values, damn it, no matter how many times you press Enter, 
and it's not going to shift until it has them! In other words, 
user-unfriendly.

This is related to my big bug-bear with most text editors where keys 
such as left, right, backspace and delete don't stop at the ends of a 
line but keep going to previous or next lines.)

> 	The parse command has lots of fancy options allowing for defining fixed
> column positions
>
> parse pull 0 a 5 b 8 c

> parse pull 5 a 0 b "5" 4 c "9"

That's easy string processing, you don't really need i/o system support: 
get the whole line as a string then slice it for the various fields.

> 	For many years, FORTRAN couldn't even handle variable width input from
> the keyboard.

> 	READ(5, 1100, END=50, ERR=100) A, B, C
> 1100	FORMAT("I8, X, I8, X, I8")

I spent a year writing interactive Fortran IV, I'm fairly sure it was 
possible but I couldn't tell you how.

>    Ada.Text_IO.Put ("Enter three integers => ");
>
>    Ada.Integer_Text_IO.Get (A);
>    Ada.Integer_Text_IO.Get (B);
>    Ada.Integer_Text_IO.Get (C);

I admire Ada in many ways, but this ...

>> When reading name, file and string items rather than integers, the split
>> method doesn't deal with embedded quotes. Probably there are bigger guns
>> you can bring out to deal with more elaborate input, but it starts to
>> get further away from beginner level.)
>
> 	Typically, if doing interactive input, you ask for ONE item at a time,
> and accept the entire line as the response.

You can't really draw the line like that. This sort of input can used 
for live input from a keyboard, from an input file, or a input file 
redirected so that it appears to come from the keyboard.

  So embedded quotes aren't a
> problem. OR you do your own parsing on the line if multiple items are
> expected, only reading more from the console when you've run out of data.
>
> 	Ad hoc parsing of user input is going to be difficult in any language.

But you wouldn't use this for that. I'd use these 'readln' methods for 
reading formatted text files; I showed a PPM header example; for 
text-mode images, 'read' can also be used.

Then there are text configuration files, or project description files, 
or files contain lists of 3D data, or comma- or tab-separated data 
files, simple command scripts....

There is a huge range of possible uses for a crude read/readln feature 
where verification at the i/o level is not really necessary. (If the 
width, image values of a PPM out of range, then you check that at the 
application level.)

Anything that is not line-oriented, or that needs very precise parsing 
such as code, would just use a different approach.

-- 
Bartc