[repost as original disappeared]
On 27/10/2016 12:41, Steve D'Aprano wrote:
On Thu, 27 Oct 2016 09:42 pm, BartC wrote:
I don't need one character at a time. I want to pause everything else, ask
the user a question, and wait for them to enter an entire line.
And no, I don't want to reinvent the wheel and build up line editing from
character editing myself. I don't want to have to handle backspacing and
navigation myself.
You're just throwing the ball into someone else's court then.
YOU don't want such features to be part of a language, but you expect
others to be able to write text-mode editors, IDEs, file-managers, games
etc without them?
Presumably you're OK with those features being available in a GUI
environment? So why the discrimination?
Text-apps aren't so common now but I get the impression that you would
never have found this stuff useful.
Feel free to give an answer. Apart from reinventing the wheel and building
functionality that Python already supports, what do you use non-blocking
keyboard input for? Can you give some examples of how you might use it?
I didn't even know what non-blocking meant until this thread.
But suppose you're writing an app such as a debugger, or interpreter, or
anything that keeps going until interrupted or controlled by some key
event. If you're executing a billion instructions per second you don't
want to keep stopping every N instructions to ask the user for any
special requests, or to press Enter to continue.
Is that good enough?
Doubtless your solution would be some large sledgehammer to crack this
particular nut.
How about Lisp? Scheme? Fortran? Java? C#? Objective-C? Dylan? Forth? Well
I'd completely believe Forth has this, I think you'd like Chuck Moore, I
think the two of you think in similar ways.
Cobol? Hypertalk? Inform 7? Bash? Haskell?
There must be *some* language other than your own that offers this feature,
if it is as obvious, useful, simple and basic and you claim.
I'm not familiar with that many languages. However if you google for
'<language> non-blocking keyboard' then it seems quite a few people are
interested in the feature!
But I seem to remember in a previous thread that Python had some problem
even with line-buffered input. Something to do with only getting a line
of input as a string then needed to do some processing to read
individual elements, IIRC.
O_o
Um, of course it gets a line of input as a text string. What would you
expect to get the user's text as? A bitmap?
print "Enter 3 numbers: "
readln a,b,c
I'm fairly sure this kind of input was common in plenty of other
languages. But maybe even that is being frowned on now; /that/ wouldn't
surprise me either.
(FWIW my own language does strive to have this basic stuff built it. But
getting full keyboard and console handling working as I want it across
both Windows and Linux is challenging. It's a bit easier on Windows as,
even though you're using a console, you have the full resources of the
Win32 API to draw on.
On Linux you can't assume any such resources except some apparently
1970s-style terminal handling, from what I can figure out.)
And possibly not even that. If your script is running as a cron job, I
believe that there's no terminal attached, and possibly no stdin or stdout.
I don't remember the details.
The same argument as before. So we don't have print() as part of the
language either before there might not be a stdout?!
The fact is that if I want to run an editor under Linux, I will need a
display, and a keyboard, and I want to have the means to use them.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
