Why doesn't Python include non-blocking keyboard input function?
Chris Angelico
rosuav at gmail.com
Fri Oct 28 13:55:57 EDT 2016
More information about the Python-list mailing list
Fri Oct 28 13:55:57 EDT 2016
- Previous message (by thread): Why doesn't Python include non-blocking keyboard input function?
- Next message (by thread): Why doesn't Python include non-blocking keyboard input function?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Oct 29, 2016 at 4:50 AM, Terry Reedy <tjreedy at udel.edu> wrote: > 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? > 16 slots, each 16 bits (8 bits character, 8 bits scan code). I think it filled at 15, though, from memory; if the head and tail pointers are equal, the buffer is empty, ergo the buffer cannot completely fill. That's where the classic "bip" of keyboard-buffer-full came from. ChrisA
- Previous message (by thread): Why doesn't Python include non-blocking keyboard input function?
- Next message (by thread): Why doesn't Python include non-blocking keyboard input function?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list