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

[Chris Angelico]

On Tue, Oct 25, 2016 at 11:09 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> 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.
>
> Each process can have its own PTY with a separate virtual keyboard
> interface. The main problem is that the Unix terminal interface is quite
> old and crude.

Or no PTY at all. And yes, it is crude... all it can do is allow input
of arbitrary text. You can't draw a self-portrait, you can't take a
photograph, you can't enter a mouse gesture. Terribly crude. And
perfect for anything that uses text.

>> In fact, even in a single-user single-process system, polling is a bad
>> idea - it means that nothing can go to sleep.
>
> Yes, spinning is bad. However, there are nicer ways to poll: select,
> poll, epoll...

What's the point of using select etc when you care about only one input?

>> Unless, of course, you want to reimplement the whole concept of
>> blocking calls on top of non-blocking ones, in which case... why?!?
>
> Blocking calls are evil.

Oh, that's why. Got it. So because blocking calls are fundamentally
evil, we have to... what? What's so bad about them? Remember, not
every program is a server handling myriad clients.

ChrisA