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

[Marko Rauhamaa]

Nobody <nobody at nowhere.invalid>:

> On Mon, 24 Oct 2016 11:14:05 -0700, jladasky wrote:
>> I gather that non-blocking keyboard input functions aren't the
>> easiest thing to implement. They seem to depend on the operating
>> system.
>
> Indeed. It's somewhat harder to implement one on an OS which doesn't
> take it for granted that the system actually *has* a keyboard (i.e.
> Unix).

I don't think that's very relevant.

> [...]
> controlling terminal, or the terminal associated with stdin [...]
>
> Other complications include the fact that, if the process isn't part
> of the terminal's foreground process group, attempting to read from
> the terminal (even a non-blocking read) will typically suspend the
> process (unless you ignore SIGTTIN). And also the fact that the
> terminal itself may be line buffered, so the computer has no idea of
> what's being typed on it until Return/Enter (or Send, etc) is pressed.

Arcane schemes that reflect ancient realities. Unix came about when
wasting CPU cycles processing terminal commands was considered
extravagant -- CPU cycles were charged to the customers. Nowadays, of
course, the CPU processes all keyboard events and commits even more
atrocious things like micromanages individual pixels on the screen and
encrypts and decrypts all external communication.

> [...]
>
> tl;dr: Unix is not MS-DOS.

Thankfully, you don't need to run your program from a terminal. You can
interpret keyboard events any way you want if your program is an X11 or
Wayland client, and forget all about TTYs, baud rates, parity bits,
hangups etc.

In fact, that's what emacs does, for example. It can operate in a
terminal (and I take advantage of that every day) but I'm typing this in
emacs running under X11.


Marko