based only on keyb scancodes, one
can use own LUTS and flags to replicate the unicode
input. I personally never wrote apps with multilingual text input though.
Seems that for keyboard input everything is already invented and
well-established.
Below is a minimal app showing pressed keys.
Try switchi
On 10/29/2016 06:16 PM, BartC wrote:
> An editor is either line-oriented or it isn't. Free-flowing English text
> usually isn't, but most program code is. And a line-oriented editor
> should have hard stops at the line ends. (IMO which apparently isn't
> shared by anyone else on the planet.)
Vi
On 29/10/2016 23:21, Dennis Lee Bieber wrote:
On Sat, 29 Oct 2016 22:11:31 +0100, BartC declaimed the
following:
(Non-line-oriented would mean it just keeps sitting there until it's
read three values, damn it, no matter how many times you press Enter,
and it's not going to shift until it has
On Tuesday, October 25, 2016 at 11:02:47 AM UTC+1, BartC wrote:
> On 25/10/2016 07:39, Steven D'Aprano wrote:
>
> >> I gather that non-blocking keyboard input functions aren't the easiest
> >> thing
> >> to implement. They seem to depend on the oper
On 29/10/2016 17:27, Dennis Lee Bieber wrote:
On Sat, 29 Oct 2016 15:32:16 +0100, BartC declaimed the
following:
I still think a beginner would much prefer something along the lines of
'readln a,b,c' (and I still think that's more intuitive).
Then I would suggest using something lik
On 29/10/2016 15:53, Chris Angelico wrote:
On Sun, Oct 30, 2016 at 1:32 AM, BartC wrote:
BTW the functionality of my 'readln a,b,c' differs from the above.
Separators can be anything reasonable. When eol is encountered, it will read
zeros. And errors are not handled: any non-numeric will yield
On 29/10/2016 16:24, Steve D'Aprano wrote:
On Sun, 30 Oct 2016 01:32 am, BartC wrote:
(BTW the functionality of my 'readln a,b,c' differs from the above.
Separators can be anything reasonable. When eol is encountered, it will
read zeros. And errors are not handled: any non-numeric will yield ze
Am 29.10.16 um 16:32 schrieb BartC:
I still think a beginner would much prefer something along the lines of
'readln a,b,c' (and I still think that's more intuitive).
(The first programming exercises I ever did involved typing in integers
from the user, and sorting them or working out if they mad
On 29/10/2016 15:19, Steve D'Aprano wrote:
On Sat, 29 Oct 2016 10:53 pm, BartC wrote:
But I'd like to see Python running on a 64KB system
(Micropython doesn't count!).
Hmmm. So tell me... how do you expect Python to run on tiny systems by
*adding* new features?
Regardless of how "small" thi
On Sun, 30 Oct 2016 01:32 am, BartC wrote:
> (BTW the functionality of my 'readln a,b,c' differs from the above.
> Separators can be anything reasonable. When eol is encountered, it will
> read zeros. And errors are not handled: any non-numeric will yield zero.
Ah, in other words it is a toy, utt
On Sun, Oct 30, 2016 at 1:32 AM, BartC wrote:
> BTW the functionality of my 'readln a,b,c' differs from the above.
> Separators can be anything reasonable. When eol is encountered, it will read
> zeros. And errors are not handled: any non-numeric will yield zero.
People will disagree as to what i
On 29/10/2016 14:51, Dennis Lee Bieber wrote:
On Sat, 29 Oct 2016 12:53:35 +0100, BartC declaimed the
following:
BTW what does reading three integers from the user look like in Python?
On one line, or on three lines?
(Python 2.7)
ln = raw_input("Enter three integers separated by s
On Sat, 29 Oct 2016 10:53 pm, BartC wrote:
> On 29/10/2016 02:04, Steve D'Aprano wrote:
>> On Fri, 28 Oct 2016 05:09 am, BartC wrote:
>
>>> For years I've had discussions in comp.lang.c about things that C should
>>> or should not have.
>
>> Bart, don't be naive. The C language isn't going to "a
On 29/10/2016 02:04, Steve D'Aprano wrote:
On Fri, 28 Oct 2016 05:09 am, BartC wrote:
For years I've had discussions in comp.lang.c about things that C should
or should not have.
Bart, don't be naive. The C language isn't going to "acquire a slick new
enhancement" based on a few emails on c
On Sat, Oct 29, 2016 at 11:13 AM, Steve D'Aprano
wrote:
> On Sat, 29 Oct 2016 02:03 am, Chris Angelico wrote:
>
>> born in those lackadaisical days when "Extended ASCII" was a single
>> thing, because the rest of the world didn't exist
>
> I know you're being sarcastic, but "extended ASCII" *never
On Fri, 28 Oct 2016 05:09 am, BartC wrote:
> And I've seen things like 'import msvcrt', 'import winapi' in Python
> code, and then there's all that stuff with ctypes.
Right. Not everything needs to be a feature of the language itself,
especially if it is operating system dependent and can be dele
On Sat, 29 Oct 2016 02:28 am, BartC wrote:
>> By using the name of a Unix system call, one might think so.
>
> Python is cross-platform, isn't it?
The os module isn't. It is specifically designed for OS-specific functions.
There's lots of OS-specific functionality in Python. In general, Python
On Sat, 29 Oct 2016 02:03 am, Chris Angelico wrote:
> born in those lackadaisical days when "Extended ASCII" was a single
> thing, because the rest of the world didn't exist
I know you're being sarcastic, but "extended ASCII" *never* was a single
thing, even for Americans who ignored the rest of
NKEY$ doesn't even test the keyboard for presses, but is
>>> only retrieving the next item from the keyboard input /buffer/ (which
>>> that
>>> article goes on to mention used to be part of a dedicated hardware chip,
>>> but now is a software/interrupt mai
On 10/28/2016 11:03 AM, Chris Angelico wrote:
On Sat, Oct 29, 2016 at 1:54 AM, Dennis Lee Bieber
wrote:
https://en.wikibooks.org/wiki/QBasic/Advanced_Input
indicates that INKEY$ doesn't even test the keyboard for presses, but is
only retrieving the next item from the keyboard input /b
On 28/10/2016 15:28, Grant Edwards wrote:
On 2016-10-27, BartC wrote:
On 27/10/2016 23:31, Chris Angelico wrote:
When you exec to a process, you provide multiple arguments, not a
single combined string.
Really, there could be dozens of arguments? Windows' CreateProcess() (if
that's the sam
On 10/28/2016 06:28 AM, Chris Angelico wrote:
> On Fri, Oct 28, 2016 at 11:12 PM, Terry Reedy wrote:
>> The only specification he has given is reference to the BASIC INKEY$
>> variable. I don't know how consistent this was across different BASICs. I
>> looked in Microsoft's GW-BASIC reference an
On Sat, Oct 29, 2016 at 1:54 AM, Dennis Lee Bieber
wrote:
> https://en.wikibooks.org/wiki/QBasic/Advanced_Input
> indicates that INKEY$ doesn't even test the keyboard for presses, but is
> only retrieving the next item from the keyboard input /buffer/ (which that
> article goes o
On 2016-10-27, BartC wrote:
> On 27/10/2016 23:31, Chris Angelico wrote:
>> When you exec to a process, you provide multiple arguments, not a
>> single combined string.
>
> Really, there could be dozens of arguments? Windows' CreateProcess() (if
> that's the same thing) has ten of which one is t
Am 28.10.16 um 12:30 schrieb Marko Rauhamaa:
Christian Gollwitzer :
Am 28.10.16 um 10:59 schrieb Marko Rauhamaa:
I don't know. How would you implement "less" in Python? How would you
implement "nethack" in Python?
On my system:
Apfelkiste:~ chris$ otool -L /usr/bin/less
/usr/bin/less:
On Fri, Oct 28, 2016 at 11:12 PM, Terry Reedy wrote:
> The only specification he has given is reference to the BASIC INKEY$
> variable. I don't know how consistent this was across different BASICs. I
> looked in Microsoft's GW-BASIC reference and it says that it returns '',
> 'x', or '0x'. This
On 10/28/2016 1:05 AM, Michael Torrie wrote:
Sure you can't get a keyboard scancode when you're in terminal.
As you note in your followup, Marko and Bart want to be able to respond,
for instance, to left and right shift, separately and differently.
Ascii terminals only send and receive ascii
On Fri, 28 Oct 2016 09:02 am, BartC wrote:
> I notice that when it comes to reading command-line arguments, then
> Python's sys.argv presents them as a list, not one long string.
Yes, just like the shell presents it to Python. It would be silly for Python
to take the list of strings it receives,
On 28/10/2016 11:35, Marko Rauhamaa wrote:
BartC :
On 28/10/2016 10:22, Christian Gollwitzer wrote:
So "less" in C uses ncurses. You can do the same in Python, "import
curses" - instead of fiddling with terminal escape characters you
leave that to a library, just like less does it.
As I comm
BartC :
> On 28/10/2016 10:22, Christian Gollwitzer wrote:
>> So "less" in C uses ncurses. You can do the same in Python, "import
>> curses" - instead of fiddling with terminal escape characters you
>> leave that to a library, just like less does it.
>
> As I commented further up the thread, I tri
Christian Gollwitzer :
> Am 28.10.16 um 10:59 schrieb Marko Rauhamaa:
>> I don't know. How would you implement "less" in Python? How would you
>> implement "nethack" in Python?
>
> On my system:
>
> Apfelkiste:~ chris$ otool -L /usr/bin/less
> /usr/bin/less:
> /usr/lib/libncurses.5.4.dylib (
On 28/10/2016 10:22, Christian Gollwitzer wrote:
Am 28.10.16 um 10:59 schrieb Marko Rauhamaa:
So "less" in C uses ncurses. You can do the same in Python, "import
curses" - instead of fiddling with terminal escape characters you leave
that to a library, just like less does it.
As I commented
Am 28.10.16 um 10:59 schrieb Marko Rauhamaa:
Christian Gollwitzer :
Am 28.10.16 um 09:33 schrieb Marko Rauhamaa:
I am just not convinced that so many people need to implement
something like readline.
I don't know. How would you implement "less" in Python? How would you
implement "nethack" in
Christian Gollwitzer :
> Am 28.10.16 um 09:33 schrieb Marko Rauhamaa:
> I am just not convinced that so many people need to implement
> something like readline.
I don't know. How would you implement "less" in Python? How would you
implement "nethack" in Python?
Well, Python does offer it all. Yo
Am 28.10.16 um 09:33 schrieb Marko Rauhamaa:
Christian Gollwitzer :
I still believe that it is not a "basic functionality". You need it,
if you want to program a text editor or similar thing, but without
using a real GUI. This is a small niche.
I disagree. It's a very large group of programs.
Christian Gollwitzer :
> I still believe that it is not a "basic functionality". You need it,
> if you want to program a text editor or similar thing, but without
> using a real GUI. This is a small niche.
I disagree. It's a very large group of programs. For example, CPython's
input() function put
available with an
import.
Sure you can't get a keyboard scancode when you're in terminal. But you
can get "keystrokes" as it were, without having to read an entire line
from standard in. I use editors and programs all the time which are
interactive (they don't buffer keyboard
On 10/27/2016 11:05 PM, Michael Torrie wrote:
> On 10/27/2016 04:07 AM, Terry Reedy wrote:
>> As I and others have said, those keyboard functions are not available on
>> text terminals. I predict that keyboard functions that so not work on
>> all systems will never become built-ins. But some ar
ou can't get a keyboard scancode when you're in terminal. But you
can get "keystrokes" as it were, without having to read an entire line
from standard in. I use editors and programs all the time which are
interactive (they don't buffer keyboard input into lines) in the
ter
On 28/10/2016 01:08, Chris Angelico wrote:
On Fri, Oct 28, 2016 at 10:45 AM, BartC wrote:
On 27/10/2016 23:31, Chris Angelico wrote:
When
you exec to a process, you provide multiple arguments, not a single
combined string.
Really, there could be dozens of arguments? Windows' CreateProcess(
On Fri, Oct 28, 2016 at 10:45 AM, BartC wrote:
> On 27/10/2016 23:31, Chris Angelico wrote:
>>
>> When
>> you exec to a process, you provide multiple arguments, not a single
>> combined string.
>
>
> Really, there could be dozens of arguments? Windows' CreateProcess() (if
> that's the same thing)
On 27/10/2016 23:31, Chris Angelico wrote:
On Fri, Oct 28, 2016 at 9:02 AM, BartC wrote:
I notice that when it comes to reading command-line arguments, then Python's
sys.argv presents them as a list, not one long string.
And the list is just a series of strings, so needing to know whether any
On Fri, Oct 28, 2016 at 9:02 AM, BartC wrote:
>
> I notice that when it comes to reading command-line arguments, then Python's
> sys.argv presents them as a list, not one long string.
>
> And the list is just a series of strings, so needing to know whether any
> parameter was a number or whatever
On 27/10/2016 19:09, BartC wrote:
On 27/10/2016 17:13, Steve D'Aprano wrote:
On Fri, 28 Oct 2016 12:13 am, BartC wrote:
print "Enter 3 numbers: "
readln a,b,c
How is the interpreter supposed to know that a, b, c are numbers? What
sort
of numbers? 16-bit integers, 80-bit floats, Bignum
BartC wrote:
"There's a room in your house with no door to it; how do I get in?"
"There's no need for a door because no one ever uses that room! But you
can get in through the chimney - if you /have/ to."
It's not like that. The room *does* have a door, it's just
that it's in different places
On 27/10/2016 17:13, Steve D'Aprano wrote:
On Fri, 28 Oct 2016 12:13 am, BartC wrote:
Doubtless your solution would be some large sledgehammer to crack this
particular nut.
*shrug*
Python's a pretty high-level language. Not every low-level feature needs to
be part of the Python language. Th
out them?
Ah, now we're getting somewhere: I'm starting to get a hint of what this
feature might be useful for. Okay.
Sure, I'll accept that perhaps this feature of non-blocking keyboard input
does have its use-cases. I might even revise my plucked-from-thin-air
figure of 97% down
On 2016-10-27, Terry Reedy wrote:
> When I used unix in the 1980s, the full screen ran csh until one started
> another full screen application. MSDOS was the same. Every contemporary
> photo of modern Linux or Mac I have seen has a desktop with windows just
> like Windows. Do people on Linux
On 2016-10-27, Marko Rauhamaa wrote:
> Grant Edwards :
>> I've offered a few times to extend the Linux pty driver to support the
>> same set of ioctl calls that a tty does (so that it could be used in
>> place of a tty generally), but I've never gotten any response.
>
> Ah, Linux kernel politics a
BartC :
> 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.
In mobile computing, such wakeups drain the battery.
Marko
--
https://mail.python.org/mailman/listinf
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 unt
ntire 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.
>> Those are not rhetoricial questions.
Feel free to give an answer. Apart from reinventing the wheel
On 27/10/2016 11:07, Terry Reedy wrote:
On 10/26/2016 9:12 PM, BartC wrote:
On 27/10/2016 00:30, Terry Reedy wrote:
So how does your tkinter example work in such a server?
Without X-windows available, there would be no point, and it will not
work. I presume including the X window subsystem
BartC :
> "There's a room in your house with no door to it; how do I get in?"
>
> "There's no need for a door because no one ever uses that room! But
> you can get in through the chimney - if you /have/ to."
+1
> On Linux you can't assume any such resources except some apparently
> 1970s-style t
Terry Reedy :
> Do people on Linux still commonly use full-screen, no window text
> editors like the one I had?
I occasionally switch on one of the alternate VTs, which are not running
any GUI.
However, I constantly use -- in fact, as I type, I'm using -- a program
running in a PTY environment. I
languages as (for example) Ruby,
Javascript, Lua, Swift, Tcl, and (not quite as well) bash, Java, Julia. Which
of these languages offer non-blocking keyboard input as a standard part of the
language?
That doesn't surprise me either. Even implementation languages such as C
tend to shy away from
ne, that Python does not include 'non-blocking keyboard input
functions', is not true.
Some things *can* be simplified. I gave one example previously. While
writing this, I realized that with a little work, I could automate all
the bindings for IDLE menu item event handlers.
(I&
On 2016-10-27 03:05 AM, Terry Reedy wrote:
When I used unix in the 1980s, the full screen ran csh until one started
another full screen application. MSDOS was the same. Every contemporary
photo of modern Linux or Mac I have seen has a desktop with windows just
like Windows. Do people on Linux s
On 10/27/2016 1:49 AM, Marko Rauhamaa wrote:
Terry Reedy :
On 10/26/2016 8:33 AM, Marko Rauhamaa wrote:
Maybe there should be some way to get the raw events from the PTY.
PTY? Must be Linux-specific. Most beginners are not on Linux.
A PTY is an emulated console (https://en.wikipedia.org/
you are
asking for? Who needs them? Why should it be a language feature?
Those are not rhetoricial questions.
Python falls neatly into the same niche of languages as (for example) Ruby,
Javascript, Lua, Swift, Tcl, and (not quite as well) bash, Java, Julia. Which
of these languages offer non
Grant Edwards :
> I've offered a few times to extend the Linux pty driver to support the
> same set of ioctl calls that a tty does (so that it could be used in
> place of a tty generally), but I've never gotten any response.
Ah, Linux kernel politics are Byzantine. It's virtually impossible to
get
Terry Reedy :
> On 10/26/2016 8:33 AM, Marko Rauhamaa wrote:
>> Maybe there should be some way to get the raw events from the PTY.
>
> PTY? Must be Linux-specific. Most beginners are not on Linux.
A PTY is an emulated console (https://en.wikipedia.org/wiki/Pseudoterminal>). I don't know Windows
On 2016-10-27, Paul Rubin wrote:
> Terry Reedy writes:
>
>> Today, ethernet-connected *nix servers have no keyboard, mouse, or
>> even a directly connected terminal.
>
> Usually you ssh into them and connect to a pty which supports the
> same ioctls that a real terminal would.
On all the Unixes/
Terry Reedy writes:
> Today, ethernet-connected *nix servers have no
> keyboard, mouse, or even a directly connected terminal.
Usually you ssh into them and connect to a pty which supports the same
ioctls that a real terminal would. I use screen editors over ssh all
the time, not to mention filt
On Wed, Oct 26, 2016 at 11:39 AM, Dennis Lee Bieber
wrote:
> Curses tends to not be available on Windows as M$ hasn't implemented a
> compatible console driver.
The PDCurses library supports the Windows console. Christoph Gohlke
distributes a curses extension module based on it:
http://www.
On 10/26/2016 11:00 AM, BartC wrote:
On 26/10/2016 13:33, Marko Rauhamaa wrote:
Say you want to implement a simple, character-based shooting game where
the two guns are operated by the [Shift] keys. Unfortunately, the Unix
terminal API doesn't make that possible. You need to get the keyboard
e
On 27/10/2016 00:30, Terry Reedy wrote:
On 10/26/2016 7:18 AM, BartC wrote:
Can tkinter do it without creating a distracting pop-up window at the
same time?
Yes. I already showed how on this thread. Of course, for some text
appications, one would be better off with a Text widget than with t
On 10/26/2016 8:33 AM, Marko Rauhamaa wrote:
BartC :
Say you want to implement a simple, character-based shooting game where
the two guns are operated by the [Shift] keys. Unfortunately, the Unix
terminal API doesn't make that possible. You need to get the keyboard
events from some other API.
On 10/26/2016 7:18 AM, BartC wrote:
Can tkinter do it without creating a distracting pop-up window at the
same time?
Yes. I already showed how on this thread. Of course, for some text
appications, one would be better off with a Text widget than with the
system-specific console.
Bart, you
On 26/10/2016 13:33, Marko Rauhamaa wrote:
BartC :
On 26/10/2016 05:44, Marko Rauhamaa wrote:
(I've implemented 'keyboards' both on-screen, and on the surface of
digitising tablets (also with a hacked Casio calculator pcb when I
couldn't afford a real one). With all of those I was mainly intere
BartC :
> On 26/10/2016 05:44, Marko Rauhamaa wrote:
> (I've implemented 'keyboards' both on-screen, and on the surface of
> digitising tablets (also with a hacked Casio calculator pcb when I
> couldn't afford a real one). With all of those I was mainly interested
> in key events, not the details.
On 26/10/2016 05:44, Marko Rauhamaa wrote:
BartC :
Some people want to work at low level, without needing to drag in a GUI,
and want to do something as simple as finding out if a button has been
pressed on a standard peripheral that nearly every computer has. It
can't be that hard!
I don't c
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
BartC :
> And no one has the answered the question of how Curses or a GUI solves
> the problem of getting char or key events. Same machine, same OS, same
> keyboard, but one piece of software has apparently discovered the
> secret which is then denied to other software.
Curses, emacs, vi, bash, CP
On 10/25/2016 10:22 AM, Steve D'Aprano wrote:
> So how would you do non-blocking keyboard input? How would it work? What
> would be the interface?
Curses must allow you to do this because I've seen text-mode games made
in curses and you could do things with arrow keys, etc,
On 10/25/2016 7:45 PM, BartC wrote:
On 25/10/2016 23:58, Chris Angelico wrote:
Yes, it does. Text does not include "Home" or "Delete", but it does
include all manner of symbols that aren't on everyone's keyboards. It
makes a huge difference.
Actually TXT files can include codes such as Carri
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
On 25/10/2016 23:58, Chris Angelico wrote:
On Wed, Oct 26, 2016 at 9:30 AM, BartC wrote:
That still doesn't answer the fundamental question:
Are you looking for KEYBOARD input or TEXT input?
Does it matter that much?
Because even if you opt for TEXT, the input (when interactive whi
> On Oct 25, 2016, at 5:55 AM, Chris Angelico wrote:
>
> On Tue, Oct 25, 2016 at 11:45 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> On Tue, Oct 25, 2016 at 11:09 PM, Marko Rauhamaa wrote:
Blocking calls are evil.
>>>
>>> Oh, that's why. Got it. So because blocking calls are fund
On Wed, Oct 26, 2016 at 9:30 AM, BartC wrote:
>> That still doesn't answer the fundamental question:
>>
>> Are you looking for KEYBOARD input or TEXT input?
>
>
> Does it matter that much?
>
> Because even if you opt for TEXT, the input (when interactive w
baud rates, parity bits,
hangups etc.
That still doesn't answer the fundamental question:
Are you looking for KEYBOARD input or TEXT input?
Does it matter that much?
Because even if you opt for TEXT, the input (when interactive which is
what we're talking about) is usually chopped up i
; hangups etc.
That still doesn't answer the fundamental question:
Are you looking for KEYBOARD input or TEXT input?
Until you figure that out, nothing matters. Personally, I'd much
rather work with text than with actual keys; in the uncommon case
where I want a keystroke to trigger an a
Nobody :
> On Mon, 24 Oct 2016 11:14:05 -0700, jladasky wrote:
>> I gather that non-blocking keyboard input functions aren't the
>> easiest thing to implement. They seem to depend on the operating
>> system.
>
> Indeed. It's somewhat harder to implement one
On Mon, 24 Oct 2016 11:14:05 -0700, jladasky wrote:
> I gather that non-blocking keyboard input functions aren't the easiest
> thing to implement. They seem to depend on the operating system.
Indeed. It's somewhat harder to implement one on an OS which doesn't take
it
On Wed, Oct 26, 2016 at 3:05 AM, Steve D'Aprano
wrote:
> On Tue, 25 Oct 2016 11:49 pm, Chris Angelico wrote:
>
>> 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 contin
Steve D'Aprano :
> So how would you do non-blocking keyboard input? How would it work?
> What would be the interface?
https://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html
Marko
--
https://mail.python.org/mailman/listinfo/python-list
jlada...@itu.edu writes:
> ... I find myself asking why Python doesn't include a standard,
> non-blocking keyboard input function. I have often wanted one myself.
I agree this would be useful. Forth has a standard word KEY to read a
key, and I used it in a simple game that I wrote a
Heh, I just realised exactly the same thing. I wondered how many responses
this thread would get before somebody noticed. Thanks Random.
You're right, of course. My code blocks.
So how would you do non-blocking keyboard input? How would it work? What
would be the interface?
> It doe
On Tue, 25 Oct 2016 11:49 pm, Chris Angelico wrote:
> 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*?)
$ Fire missiles? Press Enter
On Tue, Oct 25, 2016, at 02:39, Steven D'Aprano wrote:
> Not really. I think that lots of people think they need it, but
> once they write a little utility, they often realise that it's not
> that useful. That's just my opinion, and I'm one of those guys who
> wrote one:
>
> http://code.activestat
On 10/24/2016 2:14 PM, jlada...@itu.edu wrote:
After reading this rather vague thread...
https://groups.google.com/forum/#!topic/comp.lang.python/FVnTe2i0UTY
... I find myself asking why Python doesn't include a standard,
non-blocking keyboard input function. I have often wanted one
m
Am 25.10.16 um 14:45 schrieb Marko Rauhamaa:
Chris Angelico :
On Tue, Oct 25, 2016 at 11:09 PM, Marko Rauhamaa 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
On Tue, Oct 25, 2016 at 11:45 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Tue, Oct 25, 2016 at 11:09 PM, Marko Rauhamaa 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? Rem
Chris Angelico :
> On Tue, Oct 25, 2016 at 11:09 PM, Marko Rauhamaa 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.
On Tue, Oct 25, 2016 at 11:35 PM, BartC 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
BartC :
> 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).
Ctrl-C is not the same, but it does let you intercept it and even ignore
it. Just handle signal.SIGINT.
> A very basic model of an inte
On Tue, Oct 25, 2016 at 11:09 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> There's a huge difference between a loop that calls a blocking
>> function like (raw_)input and one that calls a non-blocking function
>> like kbhit(). One of them is polite to other processes; the other is
>> not.
>
>
On 25/10/2016 12:25, Chris Angelico wrote:
On Tue, Oct 25, 2016 at 9: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.
So you use input() instead. Big deal. The
Chris Angelico :
> There's a huge difference between a loop that calls a blocking
> function like (raw_)input and one that calls a non-blocking function
> like kbhit(). One of them is polite to other processes; the other is
> not.
Each process can have its own PTY with a separate virtual keyboard
On Tue, Oct 25, 2016 at 10:14 PM, BartC wrote:
> I don't agree. Each single process shouldn't need to be aware of any of the
> others. In the same way that the raw_input() example doesn't need to take
> account of the other half-dozen Python programs all waiting on raw_input()
> at the same time (
1 - 100 of 140 matches
Mail list logo
