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

[Michael Torrie]

On 10/28/2016 06:28 AM, Chris Angelico wrote:
> On Fri, Oct 28, 2016 at 11:12 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> The only specification he has given is reference to the BASIC INKEY$
>> variable.  I don't know how consistent this was across different BASICs.  I
>> looked in Microsoft's GW-BASIC reference and it says that it returns '',
>> 'x', or '0x'.  This latter represents an extended code "described in
>> Appendix C'.  However, Appendix C only lists the standard ASCII codes 000 to
>> 128.  So I do not know what else was available and would not know from this
>> book how to emulate GW-BASIC INKEY$.
> 
> The return values from INKEY$ are CHR$(0) + "H" for up-arrow, "P" for
> down-arrow, and I think "K" and "L" for left and right. F1 is CHR$(0)
> + ";", and the next nine function keys are the subsequent ASCII
> characters (";<=>?@ABCD"), although F11 and F12 are different, and I
> don't remember what they are. The codes don't really have any meaning
> in ASCII - they're just the scan codes, as represented in strings.
> (CHR$(0) is equivalent to "\0" in saner languages.)
> 
> This is from memory, but I spent a *ton* of time in BASIC in my
> earlier days, and there are things you never forget :)

And FreeBASIC faithfully emulates this for all its supported platforms,
terminals or graphics mode (fakes a screen buffer in a window).

I'm sure someone could make a python module that offered inkey() on any
platform in terminals and consoles based on raw input, or using win32
console api calls.  But I am not sure it belongs in the standard
library.  Nor am I sure what codes should be returned.