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

[Chris Angelico]

On Tue, Oct 25, 2016 at 11:35 PM, BartC <bc at freeuk.com> wrote:
> On 25/10/2016 12:25, Chris Angelico wrote:
>>> You mean, something as sophisticated as press Enter to continue, or
>>> Escape
>>> to quit? Or Page Up and Page Down?
>>
>>
>> Enter to continue or Ctrl-C to quit. Just as easy.
>
>
> Ctrl-C is not the same; that will just abort (without doing proper
> termination such as saving your data, or even just asking the user to
> confirm).

In Python, Ctrl-C raises KeyboardInterrupt. If you want to save your
data, use standard exception handling. (And asking to confirm? Isn't
that exactly what "Press Enter to continue or Ctrl-C to abort" *is*?)

>>> But why the need to have to use someone else's massive great wheel? Both
>>> Curses and wxPython are completely over the top IMO for something so
>>> fundamental.
>>
>>
>> Fundamental? What exactly is fundamental about key-based input? Much
>> more fundamental is character-based input, where you request *text*
>> from the user. How often do you care whether someone pressed '1' on
>> the top row as compared to '1' on the numeric keypad?
>
>
> I don't think I've made that distinction.

No, but that's exactly what happens when you switch from
character-based input to key-based. You can't have both. Either you
care about text, or you care about buttons being pressed.

> A very basic model of an interactive text-based computer has input at one
> end and output at the other. And a keyboard is the obvious choice for input
> (a bit easier than voice and less crude than punched cards or tape).
>
> You can do a lot of stuff with line-based input, but how do you think /that/
> gets implemented? At some point it needs to be a character at a time or a
> key at a time; the requirement is there.
>
> Take away a keyboard, real or virtual, from a development computer (or even
> one used to check your bank account or go on forums), and see how far you
> get.

So? My programs don't care about that. They care about text. Where
that text comes from is immaterial - it could be the keyboard, it
could be the mouse (middle-click paste), it could be a file (stream
redirection), it could be anything else.

>> Much more commonly, you simply ask for
>> input from the user, and get back a line of text. The user might have
>> edited that line before submitting it, and that's a feature, not a
>> bug.
>
>
> Yeah, 'kill dwarf with axe' and such. It works but it's limited.
>
> Try and write a program where the keys represent the notes on a piano, and
> pressing each key plays the corresponding note from speaker.
>
> Having to press Enter after each one is going to cramp your style a bit!

And that's where you should be using a proper UI library - I would do
this with a GUI, but you could also use ncurses.

> And don't tell me this is advanced because I was doing stuff like this
> decades ago. (Of course now I wouldn't have a clue how to make it generate
> sounds.)

I've been doing stuff like this for decades too - and decades ago, I
was doing pretty advanced stuff. False line of argument. It sounds
like "I'm older than you, and must know better", and that wasn't much
good for Alice and the Lory either.

> But the point is, it is just the one function; how it's implemented is not
> relevant. It's the kind of function that it would be nice to have /as
> standard/ in any language without being told that being able to deal with
> key-at-a-time input is an advanced topic!

How often do you really need this functionality, and what are you
willing to give up for it? Normally, if you want that kind of thing,
you need to reach for a GUI/TUI toolkit. Yaknow, like Steve said in
the first place.

ChrisA