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

[Terry Reedy]

On 10/26/2016 9:12 PM, BartC wrote:
> On 27/10/2016 00:30, Terry Reedy wrote:

>> Bart, you appear to have been fortunate enough to be spoiled by learning
>> programming on microcomputers, where the terminal and computer are
>> combined into one unit, so that the computer, and potentially the
>> programmer, have access to user input actions.
>
> Actually, I first used machines such as pdp10 and pdp11. Those mostly
> used serial terminals, a mystery to me, and they still are. It seems
> Unix is keen to propagate the mystery.

OK, you got spoiled later ;-).  I share your frustration a bit.

>> However, Python was not
>> developed on, and in not limited to use on, such machines.  Today,
>> ethernet-connected *nix servers have no keyboard, mouse, or even a
>> directly connected terminal.
>
> So how does your tkinter example work in such a server?

Without X-windows available, there would be no point, and it will not 
work.  I presume including the X window subsystem on a linux (server) 
build is optional.  Last I knew, all of the linux machines with a 
CPython buildbot either do not have X or prohibit the buildbot from 
using it.

Compiling _tkinter.c is optional and many (most?) Linux distributions 
put tkinter.py, idlelib/*.py, and turtle.py in a separate package.  If a 
buildbot tries to run gui tests on linux machines without X available, 
an exception is raised, something like 'Failed to connect to the X 
subsystem'.  (It has been 3 years since I cause one of those.)

If the server includes X and tkinter and one connects (likely as admin) 
with a X-terminal or emulator, I expect that tk and tkinter should work. 
  Whether X will let an invisible window keep keyboard focus, I will not 
know until someone tries it.  Perhaps 99+% of Tcl/tk works the same 
across platforms.

> As I don't
> understand the argument that a language shouldn't have a basic keyboard
> API because some computers it could run on might not have a keyboards.

As I and others have said, those keyboard functions are not available on 
text terminals.  I predict that keyboard functions that so not work on 
all systems will never become built-ins.  But some are available with an 
import.

Python optionally comes with a sophisticated keyboard api.  The PSF 
(python.org) CPython builds for Windows and Mac include that API.  On 
Windows, so is the required tcl/tk build.  The premise of the subject 
line, that Python does not include 'non-blocking keyboard input 
functions', is not true.

Some things *can* be simplified.  I gave one example previously.  While 
writing this, I realized that with a little work, I could automate all 
the bindings for IDLE menu item event handlers.

> (I've looked at X Windows; bloody hell, it makes Win32/GDI look like
> child's play.)

This may have helped persuade three different language groups to 
piggyback on the work of tcl folk.  Keeping up with Apple's series of 
graphics systems has also been a hassle.

-- 
Terry Jan Reedy