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
--
https://mail.python.org/mailman/listinfo/python-list
