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

[Chris Angelico]

On Sat, Oct 29, 2016 at 1:54 AM, Dennis Lee Bieber
<wlfraed at ix.netcom.com> wrote:
> https://en.wikibooks.org/wiki/QBasic/Advanced_Input
> indicates that INKEY$ doesn't even test the keyboard for presses, but is
> only retrieving the next item from the keyboard input /buffer/ (which that
> article goes on to mention used to be part of a dedicated hardware chip,
> but now is a software/interrupt maintained buffer).

True, but in practice, it's the same thing. The keyboard buffer ring
gets populated by the interrupt handler, and INKEY$ looks at the
buffer, sees if it's empty (return ""), and if not, consumes and
returns one key.

>         And it defines the extended return value as the "scan code" for the
> keyboard. Which would just be a number assigned to the key position, and
> might (back in those days) have had different values going from machine to
> machine. Most of the modifier keys (shift, control) in those days did not
> produce their own codes.

Yes, but who ever writes programs that run on multiple different
computers? Just hard-code those scan codes everywhere, it'll be fine!

ChrisA
born in those lackadaisical days when "Extended ASCII" was a single
thing, because the rest of the world didn't exist