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

BartC bc at freeuk.com
Tue Oct 25 07:14:38 EDT 2016


On 25/10/2016 11:39, Dennis Lee Bieber wrote:
> On Tue, 25 Oct 2016 11:02:31 +0100, BartC <bc at freeuk.com> declaimed the
> following:
>
>> This gives you the ability to do (2) above. From that, you could do (1)
>> (echoing) and go on to build full line-orientated input. But you had
>> complete control.
>>
>> So, why has it all become so difficult?
>
> 	Because you now have an interrupt driven operating system with buffered
> line handling between you and the hardware. The OS is handling things like
> back-space/delete, <cr><lf> (from a single keypress -- for those systems
> that use both for line ending), previous line recall/history.
>
> 	Your polling loop on a status register basically meant nothing else was
> happening on that computer until you retrieved a character

Only if you were specifically waiting for a key press. For the 
requirement in the other thread (see link in OP), it just needed to know 
if a key had been pressed; that would be very quick (I can't remember if 
that status bit latched or not.)

Anyway the next step would have been to wire up the status bit to an 
interrupt line.

  and passed it on
> to whatever program had requested it. Something doable on a
> single-user/single-task system, but totally at odds with any system running
> a few dozen separate processes.

I don't agree. Each single process shouldn't need to be aware of any of 
the others. In the same way that the raw_input() example doesn't need to 
take account of the other half-dozen Python programs all waiting on 
raw_input() at the same time (which are all waiting for the same keyboard).

> 	Hardware peripherals are now the domain of the OS, and mere users are
> supposed to request the OS for data... That means OS specific methods for
> bypassing the convenience mode of "cooked" input.

Fine, then let the OS provide the appropriate means if the user program 
is not allowed to directly access the hardware. getch() and kbhit() are 
crude but they will do for simple programs. But they are not part of the 
OS. Implementing the equivalent via calls to Win32 is horrendous (and to 
Linux not much better).

(BTW the computer I was using in 1976 had 160 simultaneous users. And 
each had their own keyboard. Now usually there is just one keyboard...)

-- 
bartc



More information about the Python-list mailing list