Why doesn't Python include non-blocking keyboard input function?
BartC
bc at freeuk.com
Wed Oct 26 07:18:56 EDT 2016
On 26/10/2016 02:02, Steve D'Aprano wrote:
> On Tue, 25 Oct 2016 09:02 pm, BartC wrote:
>
>>> raw_input('Press the Enter key to continue... ')
>>
>> Which doesn't work on Python 3. So even here, making it easy by using
>> line-input, it's not so straightforward.
>
> Really, Bart? You're stymied by the change of raw_input() to input() in
> Python 3? A programmer of your many years experience and skill can't work
> out how to conditionally change "raw_input" to "input" according to the
> version of the interpreter running. I don't think so.
I could probably figure it out. But how about a beginner?
(When I post Python code I try and make sure it works on both, or
specify which version.)
>> 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.
>
> *shrug* Then find a more lightweight solution. Tkinter? Something even
> lighter?
Can tkinter do it without creating a distracting pop-up window at the
same time? If not then that's too intrusive.
Curses? If I try 'import curses' (on Windows), I get 'No module named
'_curses'. Same with ncurses or Curses. Now instead of getting on with
it I have to go chasing some add-on. And if I want to share a bit of
code with someone else, then /they/ have to do the same!
My point is that this simple stuff just be included in a language.
> Maybe there is no such lightweight solution? Then that tells you that nobody
> else needed this enough to build a solution.
I find this a lot with stuff that originates on Unix or Linux.
(Do you know when I create executables that run on Linux, I have to try
and cram all the support files within the executable itself - because it
appears to be impossible to discover the path the executable was started
from. With a view to using the same or adjoining path for associated
files. When I ask about this, Oh it's never been needed!
Same with basic keyboard stuff that any microcomputer from the 80s could
do in an instant.)
> I don't know. I've never needed this enough to care to investigate. Like I
> said, it *seems* like the sort of obvious functionality every programmer
> should need all the time, but in 15 years I've never, not once, actually
> needs a non-blocking way to check for a keyboard event in a situation where
> I wasn't using something like curses or a GUI framework.
By non-blocking you mean checking if a key has been pressed rather than
waiting for it to be pressed? I use the latter ALL THE TIME when
debugging. The former less often, because if I wanted to use it to abort
huge amounts of output, I just abort the program (with Ctrl Break).
Nevertheless, it is still used sometimes, and it's there when I need it
(NOT Python):
repeat
print "A"
until testkey()
>> So, why has it all become so difficult?
>
> Build line oriented input? Why would I do that, when the OS does it?
Sometimes you want your own line-input functions because they need to be
customised to do special things. Assign special meanings to certain key
events for example.
You make it sound completely crazy like building your own OS. But I've
done this dozens of times (and yes including when there /was/ no OS), it
really isn't a big deal. Except when a language strives to make it so.
> I don't know. I've never needed this enough to care to investigate.
Try this little task. In the late 70s I was fascinated by the ability of
a teletype to do this: it would ask a Yes/No question, perhaps:
.CONFIRM (YES/NO):
But then, instead of typing YES<return> or NO<return>, if either Y or N
was pressed, it would auto-complete it, printing 'ES' or 'O' and doing a
Return for you ("." is the prompt; you have to imagine the clatter):
.CONFIRM (YES/NO): YES
.
How hard is it to do this nearly 40 years On a machines a million times
more powerful? And in Python (although I'd imagine any difficulties it
has originate outside the language and probably affect others).
Bartc
More information about the Python-list
mailing list