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

[Terry Reedy]

On 10/28/2016 11:03 AM, Chris Angelico wrote:
> 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.

'ring bugger' implies a finite limit tot he size of the queue.  Do 
either of you know what it is?

>>         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.

If I were to write inkey() for my own use or as part of a tk console 
module, I would stick with returning either the character or a mostly 
machine and OS independent name.

-- 
Terry Jan Reedy