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

[Terry Reedy]

On 10/25/2016 7:45 PM, BartC wrote:
> On 25/10/2016 23:58, Chris Angelico wrote:

>> Yes, it does. Text does not include "Home" or "Delete", but it does
>> include all manner of symbols that aren't on everyone's keyboards. It
>> makes a huge difference.
>
> Actually TXT files can include codes such as Carriage Return, Backspace
> and Tab.

These are called 'control *characters*' because, like characters, they 
are represented as encoded bytes or, now, as unicode codepoints.  'Home' 
is not a control character.  (I don't know if there is a unicode 
codepoint for it.)

>> Of course, you might want to stick your head in the sand and pretend
>> that every character has a button on your keyboard.
>
> I'm not sure of the relevance of that. There isn't a 1:1 correspondence
> between key and character code. So 'a' and 'A' might both be entered by
> pressing the key marked 'A'. With, possibly, some underlying translation
> so that the 'A' key can vary locations by locale. That isn't new.

The translation used to be done by a physically separate terminal and 
communication between computer and and terminal was via encoded bytes. 
A program could not access keystrokes because the computer never saw 
them.  Python normally runs in a terminal or console that translates 
keycodes to encoded bytes

> It doesn't seem to me that anyone is denying that key-at-a-time access
> is useful in a wide range of programs. They just seem to be unwilling to
> let it be it available in a simple, standard form.

The simple, standard form for Python, as well as for tcl, perl, and 
ruby, is as tk events.  Python accesses then via tkinter.  Other 
languages have their own version of the API.

 > We are expected to download wxPython first.

Since this is not true, why do you keep repeating it?

-- 
Terry Jan Reedy