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

[Chris Angelico]

On Tue, Oct 25, 2016 at 10:14 PM, BartC <bc at freeuk.com> wrote:
> 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).
>
> 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).

There's a huge difference between a loop that calls a blocking
function like (raw_)input and one that calls a non-blocking function
like kbhit(). One of them is polite to other processes; the other is
not. In fact, even in a single-user single-process system, polling is
a bad idea - it means that nothing can go to sleep. Unless, of course,
you want to reimplement the whole concept of blocking calls on top of
non-blocking ones, in which case... why?!?

ChrisA