Home Original page

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

Terry Reedy tjreedy at udel.edu
Tue Oct 25 09:23:24 EDT 2016 
On 10/24/2016 2:14 PM, jladasky at itu.edu wrote:
> After reading this rather vague thread...
>
> https://groups.google.com/forum/#!topic/comp.lang.python/FVnTe2i0UTY
>
> ... I find myself asking why Python doesn't include a standard,
> non-blocking keyboard input function.  I have often wanted one
> myself.  The only way that I've ever achieved this behavior is:
>
> 1) by restricting the user to pressing Ctrl-C while the program is
> running, and catching a KeyboardInterrupt; or
>
> 2) loading a heavyweight GUI like wxPython or PyQt, and using its
> event loop to intercept keyboard events.

Or load the lighter weight cross-platform tkinter GUI that comes with 
Python.  One can either make the GUI invisible or use at least a Text or 
Entry widget instead of the OS console.  The text widget comes with 
numerous key and mouse bindings, including the generic "Display glyph in 
response to press of graphics key".

Either way, if one wants to do a prolonged computation, one must either 
put it another thread or split it into chunks of limited duration, such 
50 milleseconds (1/20 second), with breaks in between that allow user 
input handling.

> I gather that non-blocking keyboard input functions aren't the
> easiest thing to implement.  They seem to depend on the operating
> system.  Still, ease of use is a primary goal of Python, and the need
> for this feature must be common.

What is not common today is to only want asynchronous keypress handing 
without the use of any GUI widget (other than the OS-supplied console).

-- 
Terry Jan Reedy
More information about the Python-list mailing list