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

Christian Gollwitzer auriocus at gmx.de
Tue Oct 25 09:03:27 EDT 2016


Am 25.10.16 um 14:45 schrieb Marko Rauhamaa:
> Chris Angelico <rosuav at gmail.com>:
>
>> On Tue, Oct 25, 2016 at 11:09 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>> 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.
>
> Myriads or not, we are talking about interactive (or reactive) programs.
> The paradigm of choice is event-driven programming.
>

I agree, which means (basically) GUI, which means event loop and all 
that stuff, making programming more inconvenient or complicated.

That reminds me of a standard "problem" with introductory programming 
texts. Many books describe the first programs along the lines of

x=input('Please enter x: ')
y=input('Please enter y: ')
print('The product is ', x*y)

Now, such programs are not useful in practice. Once you try, you will 
inevitably make errors entering the data, restart that thing multiple 
times and curse the author badly. "Real" programs either provide a GUI 
or a command line parser which allows for the correction of errors and 
entering the data in arbitrary order. Both lead to more complex programs.

Maybe some (extremely simple) option parser or GUI thingy could be 
implemented into Python directly, so that the novice doesn't have to 
bother with the details, in the sense of:

parameters({'x', double, 'y', double})
output('The product is ', x*y)

which becomes either a command line thingy with -x and -y options or a 
GUI with input fields and an output line.

	Christian



More information about the Python-list mailing list