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

[BartC]

On 29/10/2016 23:21, Dennis Lee Bieber wrote:
> On Sat, 29 Oct 2016 22:11:31 +0100, BartC <bc at freeuk.com> declaimed the
> following:

>> (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.
>
> 	There are those of us who, if we were given a prompt that said enter
> three values, would want it to take three values regardless of how many
> blank lines you enter.

Such behaviour can be programmed if it is useful for the input to be 
free-format where N items of input can be spread over any number of lines.

But it's not a good idea where line ends are meaningful (eg. marking the 
end of some input), or it is necessary to stay synchronised with line 
beginnings.

An example of such input is the command prompt in console and terminal 
windows. If I want to enter type 'python program.py' then it will end 
badly if I enter is as:

   >> python
      program.py

on two lines.

>> 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.)
>
>
> 	DEC SOS died off in the early 80s. But VI might make you happy... Not
> sure about VIM (VI IMproved).

An editor is either line-oriented or it isn't. Free-flowing English text 
usually isn't, but most program code is. And a line-oriented editor 
should have hard stops at the line ends. (IMO which apparently isn't 
shared by anyone else on the planet.)

(Not sure what the reference to SOS means. That was a TTY editor which 
didn't have navigation that I recall, while backspace and delete didn't 
really work on printed display.)


-- 
Bartc