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