Re: Why doesn't Python include non-blocking keyboard input function?
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 operating system. Still, ease of
use is a primary goal of Python, and the need for this feature must be
common.
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.
If you (generic you, not you specifically) are telling the user "press any key
to continue", then you probably shouldn't. *Any* key may not do anything. E.g.
if the user hits the Shift key. A much better interface is to specify a
specific key, and ignore anything else... in which case, why not specify the
Enter key?
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.
If you are doing something more complex, waiting on different keys to do
different things,
You mean, something as sophisticated as press Enter to continue, or
Escape to quit? Or Page Up and Page Down?
then you probably should use an existing text UI like Curses,
or a GUI like wxPython etc, rather than trying to reinvent the wheel badly.
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.
I started coding in 1976 (Christ, 40 years ago!), using teletypes.
Getting line input was easy (apparently easier than in Python now!).
What was hard was:
(1) Reading a single key-press without the user having to press
Enter (or Return as it was then)
(2) Reading that single key-press without the character being echoed to
the output
It seems like little has changed!
You needed this to do what I considered cool things. A bit limited on a
TTY but on a video display, a lot more was possible (editors, games, etc).
As for actually reading from the keyboard, the first board I made that
actually had one (it was gorgeous, with all sorts of exotic keys you
didn't find on typewriters like !, [], {}, + and Ctrl), involved this:
* Poll the byte at some specific port until the top bit changed
from 0 to 1. Then a key had just been pressed.
* The lower 7 bits was the ASCII value of the character (I don't
know what it did about cursor keys, but maybe it didn't have any.)
This gives you the ability to do (2) above. From that, you could do (1)
(echoing) and go on to build full line-orientated input. But you had
complete control.
So, why has it all become so difficult?
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
If you are on a windows platform you could use kbhit() from the msvcrt module as Steven D does in his solution on the activestate site which also works for xNIX. Worth a look at his code to see how these sort of things are done on xNIX. Alternatively you could use a couple of threads. One for your worker code and one for the keyboard entry code. Use a message queue to pass received lines from the keyboard thread to the worker thread. OK you still have to press Enter but you don't need the windows msvcrt library or xNIX termios modules. Regards John On 25/10/2016 07:39, Steven D'Aprano wrote: On Tuesday 25 October 2016 05:14, [email protected] 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 myself. The only way that I've ever achieved this behavior is: 1) by restricting the user to pressing Ctrl-C while the program is running, and catching a KeyboardInterrupt; or 2) loading a heavyweight GUI like wxPython or PyQt, and using its event loop to intercept keyboard events. I gather that non-blocking keyboard input functions aren't the easiest thing to implement. They seem to depend on the operating system. Still, ease of use is a primary goal of Python, and the need for this feature must be common. 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.activestate.com/recipes/577977-get-single-keypress/?in=user-4172944 Me and ten thousand others. If you (generic you, not you specifically) are telling the user "press any key to continue", then you probably shouldn't. *Any* key may not do anything. E.g. if the user hits the Shift key. A much better interface is to specify a specific key, and ignore anything else... in which case, why not specify the Enter key? raw_input('Press the Enter key to continue... ') If you are doing something more complex, waiting on different keys to do different things, then you probably should use an existing text UI like Curses, or a GUI like wxPython etc, rather than trying to reinvent the wheel badly. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 25/10/2016 11:39, Dennis Lee Bieber wrote: On Tue, 25 Oct 2016 11:02:31 +0100, BartC declaimed the following: This gives you the ability to do (2) above. From that, you could do (1) (echoing) and go on to build full line-orientated input. But you had complete control. So, why has it all become so difficult? Because you now have an interrupt driven operating system with buffered line handling between you and the hardware. The OS is handling things like back-space/delete, (from a single keypress -- for those systems that use both for line ending), previous line recall/history. Your polling loop on a status register basically meant nothing else was happening on that computer until you retrieved a character Only if you were specifically waiting for a key press. For the requirement in the other thread (see link in OP), it just needed to know if a key had been pressed; that would be very quick (I can't remember if that status bit latched or not.) Anyway the next step would have been to wire up the status bit to an interrupt line. and passed it on to whatever program had requested it. Something doable on a single-user/single-task system, but totally at odds with any system running a few dozen separate processes. 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 (which are all waiting for the same keyboard). Hardware peripherals are now the domain of the OS, and mere users are supposed to request the OS for data... That means OS specific methods for bypassing the convenience mode of "cooked" input. Fine, then let the OS provide the appropriate means if the user program is not allowed to directly access the hardware. getch() and kbhit() are crude but they will do for simple programs. But they are not part of the OS. Implementing the equivalent via calls to Win32 is horrendous (and to Linux not much better). (BTW the computer I was using in 1976 had 160 simultaneous users. And each had their own keyboard. Now usually there is just one keyboard...) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 concept is still the same.
>> If you are doing something more complex, waiting on different keys to do
>> different things,
>
>
> 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.
> 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? How often do you
actually need to handle Backspace as a key, rather than simply having
it remove one character? Do you actually want to distinguish between
typed keys and pasted text? 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.
When you want more flexibility than "Enter to continue or Ctrl-C to
abort", it probably *is* time to get curses or a GUI toolkit, because
you're doing something that's fundamentally different from "request
text from the user".
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 (which are all waiting for the same keyboard). > > Fine, then let the OS provide the appropriate means if the user program is > not allowed to directly access the hardware. getch() and kbhit() are crude > but they will do for simple programs. But they are not part of the OS. > Implementing the equivalent via calls to Win32 is horrendous (and to Linux > not much better). 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. In fact, even in a single-user single-process system, polling is a bad idea - it means that nothing can go to sleep. Unless, of course, you want to reimplement the whole concept of blocking calls on top of non-blocking ones, in which case... why?!? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 interface. The main problem is that the Unix terminal interface is quite old and crude. I'm guessing the raw inputs come from the /dev/input/* drivers. Unfortunately the PTYs don't come with their faked /dev/input drivers, and they would be reserved for root anyway. > In fact, even in a single-user single-process system, polling is a bad > idea - it means that nothing can go to sleep. Yes, spinning is bad. However, there are nicer ways to poll: select, poll, epoll... > Unless, of course, you want to reimplement the whole concept of > blocking calls on top of non-blocking ones, in which case... why?!? Blocking calls are evil. Marko -- https://mail.python.org/mailman/listinfo/python-list
3.5.2
Im running windows 7 pro, 64 bit. I downloaded 3.5.2 64 bit and when I try to run I get the error message api-ms-win-crt-runtime-l1-1-0.dll is missing. I loaded that file and still will not run. suggestions? thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 concept is still the same.
If you are doing something more complex, waiting on different keys to do
different things,
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).
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.
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.
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 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.)
When you want more flexibility than "Enter to continue or Ctrl-C to
abort", it probably *is* time to get curses or a GUI toolkit, because
you're doing something that's fundamentally different from "request
text from the user".
My IDE and editor that I use every day are based on 'getchx()', an
extended version of getch(). Although it is implemented on top of Win32
which is a kind of complex GUI. (getchx returns key and shift-state
information as well as character codes.)
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!
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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. > > Each process can have its own PTY with a separate virtual keyboard > interface. The main problem is that the Unix terminal interface is quite > old and crude. Or no PTY at all. And yes, it is crude... all it can do is allow input of arbitrary text. You can't draw a self-portrait, you can't take a photograph, you can't enter a mouse gesture. Terribly crude. And perfect for anything that uses text. >> In fact, even in a single-user single-process system, polling is a bad >> idea - it means that nothing can go to sleep. > > Yes, spinning is bad. However, there are nicer ways to poll: select, > poll, epoll... What's the point of using select etc when you care about only one input? >> Unless, of course, you want to reimplement the whole concept of >> blocking calls on top of non-blocking ones, in which case... why?!? > > 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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 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). Text and keyboard are completely different entities. You don't find [F1] or [Insert] or [Alt] in text nor do you distinguish between button up and button down. Also, you can't measure the timing between the characters in text. Most Unix entities are right at home with text. It's the keyboard that's problematic. The keyboard does not communicate with characters or text. Rather it emits events with keycodes. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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. Myriads or not, we are talking about interactive (or reactive) programs. The paradigm of choice is event-driven programming. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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? Remember, not >> every program is a server handling myriad clients. > > Myriads or not, we are talking about interactive (or reactive) programs. > The paradigm of choice is event-driven programming. Have you watched "Tron"? A program goes to the I/O tower to receive a message from the User. It's an active operation on the part of the program. The user cannot initiate it, only the program can. Tron is extremely accurate in this way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 is a server handling myriad clients.
Myriads or not, we are talking about interactive (or reactive) programs.
The paradigm of choice is event-driven programming.
I agree, which means (basically) GUI, which means event loop and all
that stuff, making programming more inconvenient or complicated.
That reminds me of a standard "problem" with introductory programming
texts. Many books describe the first programs along the lines of
x=input('Please enter x: ')
y=input('Please enter y: ')
print('The product is ', x*y)
Now, such programs are not useful in practice. Once you try, you will
inevitably make errors entering the data, restart that thing multiple
times and curse the author badly. "Real" programs either provide a GUI
or a command line parser which allows for the correction of errors and
entering the data in arbitrary order. Both lead to more complex programs.
Maybe some (extremely simple) option parser or GUI thingy could be
implemented into Python directly, so that the novice doesn't have to
bother with the details, in the sense of:
parameters({'x', double, 'y', double})
output('The product is ', x*y)
which becomes either a command line thingy with -x and -y options or a
GUI with input fields and an output line.
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 10/24/2016 2:14 PM, [email protected] 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 myself. The only way that I've ever achieved this behavior is: 1) by restricting the user to pressing Ctrl-C while the program is running, and catching a KeyboardInterrupt; or 2) loading a heavyweight GUI like wxPython or PyQt, and using its event loop to intercept keyboard events. Or load the lighter weight cross-platform tkinter GUI that comes with Python. One can either make the GUI invisible or use at least a Text or Entry widget instead of the OS console. The text widget comes with numerous key and mouse bindings, including the generic "Display glyph in response to press of graphics key". Either way, if one wants to do a prolonged computation, one must either put it another thread or split it into chunks of limited duration, such 50 milleseconds (1/20 second), with breaks in between that allow user input handling. I gather that non-blocking keyboard input functions aren't the easiest thing to implement. They seem to depend on the operating system. Still, ease of use is a primary goal of Python, and the need for this feature must be common. What is not common today is to only want asynchronous keypress handing without the use of any GUI widget (other than the OS-supplied console). -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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.activestate.com/recipes/577977-get-single-keypress/?in=user-4172944 Non-blocking (which your example here doesn't even do) isn't the same thing as character-at-a-time. It doesn't even imply it, technically - you could want to do other stuff and occasionally check if the user has entered a line, though *that* is even *more* involved on Windows because it means you can't do it with msvcrt.kbhit. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 to continue or Ctrl-C to abort. ^C $ Are you sure you want to abort? Press Enter to abort or Ctrl-C to abort the abort. ENTER $ Did you mean to abort? Press Enter to continue aborting, or Ctrl-C to abort aborting the abort and continue. ENTER $ Confirm abort: Enter to abort, Ctrl-C to abort. ENTER $ Abort aborted. Missiles fired. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On Wed, 26 Oct 2016 01:36 am, Random832 wrote: > 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.activestate.com/recipes/577977-get-single-keypress/?in=user-4172944 > > Non-blocking (which your example here doesn't even do) isn't the same > thing as character-at-a-time. 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 doesn't even imply it, technically - > you could want to do other stuff and occasionally check if the user has > entered a line, though *that* is even *more* involved on Windows because > it means you can't do it with msvcrt.kbhit. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
[email protected] 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 few months ago (you enter a key indicating which way you want to move). > The only way that I've ever achieved this behavior is: ... In *nix you should be able to set the tty modes with fcntl.ioctl so that reading from stdin returns immediately when you hit a key. You should be able to use select.select with zero timeout to see whether input is available. -- https://mail.python.org/mailman/listinfo/python-list
Re: 3.5.2
On 25-10-2016 2:11, Kenneth L Stege wrote: > Im running windows 7 pro, 64 bit. I downloaded 3.5.2 64 bit and when I try to > run I get the error message api-ms-win-crt-runtime-l1-1-0.dll is missing. I > loaded that file and still will not run. > suggestions? > thanks > http://lmgtfy.com/?q=api-ms-win-crt-runtime-l1-1-0.dll+missing+windows+7 -- https://mail.python.org/mailman/listinfo/python-list
Reversing \N{...} notation?
I like the clarity of using the "\N{...}" notation when creating
string literals involving Unicode chars.
Is there a built-in way to get such strings back from Python?
>>> s = 'ma\N{LATIN SMALL LETTER N WITH TILDE}ana'
>>> s
'mañana'
>>> magic(s)
'ma\\N{LATIN SMALL LETTER N WITH TILDE}ana'
I can manually rip the string apart and put it back together with
something like
>>> import unicodedata as ud
>>> ''.join(c if ord(c) < 128 else '\\N{%s}' % ud.name(c) for c in s)
'ma\\N{LATIN SMALL LETTER N WITH TILDE}ana'
but was wondering if there was some sort of .encode() trick or other
corner of the library I hadn't found.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
3rd command never executed in remote machine using paramiko
I have written below code to run 3 command in remote server interactively
But when i checked 3rd command never executed and code stuck here is my code
def execute():
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('ipaddress',username='user', password='pw')
chan=ssh.invoke_shell()# start the shell before sending commands
chan.send('cd /path to folder/test')
chan.send('\n')
time.sleep(3)
chan.send("ls -l")
chan.send('\n')
buff=''
while not buff.endswith(">"):
resp = chan.recv()
# code stuck here after 'path to folder/test >' comes in shell prompt
buff+=resp
print resp
print "test"
chan.send("ls -lh")
chan.send('\n')
time.sleep(5)
buff=''
while not buff.endswith(">"):
resp = chan.recv()
buff+=resp
print resp
if __name__ == "__main__":
execute()
When i ran i got output of ls -l but ls -lh never executed my code stuck in
first while loop. Anyone please help to resolve my issue
When i reduced bytes to read size then it executed 3rd script.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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
Re: Reversing \N{...} notation?
Tim Chase wrote:
> I like the clarity of using the "\N{...}" notation when creating
> string literals involving Unicode chars.
>
> Is there a built-in way to get such strings back from Python?
>
> >>> s = 'ma\N{LATIN SMALL LETTER N WITH TILDE}ana'
> >>> s
> 'mañana'
> >>> magic(s)
> 'ma\\N{LATIN SMALL LETTER N WITH TILDE}ana'
>
> I can manually rip the string apart and put it back together with
> something like
>
> >>> import unicodedata as ud
> >>> ''.join(c if ord(c) < 128 else '\\N{%s}' % ud.name(c) for c in s)
> 'ma\\N{LATIN SMALL LETTER N WITH TILDE}ana'
>
> but was wondering if there was some sort of .encode() trick or other
> corner of the library I hadn't found.
>>> 'mañana'.encode("ascii", "namereplace").decode()
'ma\\N{LATIN SMALL LETTER N WITH TILDE}ana'
(requires Python 3.5)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 continue or Ctrl-C to abort" *is*?) > > > $ Fire missiles? Press Enter to continue or Ctrl-C to abort. ^C > $ Are you sure you want to abort? >Press Enter to abort or Ctrl-C to abort the abort. ENTER > $ Did you mean to abort? Press Enter to continue aborting, >or Ctrl-C to abort aborting the abort and continue. ENTER > $ Confirm abort: Enter to abort, Ctrl-C to abort. ENTER > $ Abort aborted. Missiles fired. http://www.gotterdammerung.org/humor/boh13.html (Sadly, the official bofh.ntk.net is down, or I'd link to it there.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 for granted that the system actually *has* a keyboard (i.e. Unix). If you're willing to compromise and accept the use of a terminal rather than a keyboard, the next question is whether to use the process' controlling terminal, or the terminal associated with stdin (if both exist, they're probably the same terminal, but aren't required to be). Other complications include the fact that, if the process isn't part of the terminal's foreground process group, attempting to read from the terminal (even a non-blocking read) will typically suspend the process (unless you ignore SIGTTIN). And also the fact that the terminal itself may be line buffered, so the computer has no idea of what's being typed on it until Return/Enter (or Send, etc) is pressed. Aside from that, receiving key presses as they are entered means disabling canonical mode in the tty driver (which buffers input until Return or Ctrl-D are pressed, so that you can edit the input line with Backspace or Ctrl-U). That affects all processes using the terminal. If the current process is in the foreground process group, then processes in other groups probably won't be reading from the terminal ... at least until you suspend the forground process group with Ctrl-Z. So you need to install signal handlers for SIGTSTP and SIGCONT to restore the terminal settings when the process is suspended. But what should you do about any existing handlers for those signals? All things considered, requiring the user to use one of the keys that generates a signal might be simpler. Or at least not using Esc, which is about the worst possible choice, given that its normal function is as a prefix for, well, just about every control sequence (i.e. what is sent when you press a key which doesn't correspond to a printable character). tl;dr: Unix is not MS-DOS. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 an OS which doesn't > take it for granted that the system actually *has* a keyboard (i.e. > Unix). I don't think that's very relevant. > [...] > controlling terminal, or the terminal associated with stdin [...] > > Other complications include the fact that, if the process isn't part > of the terminal's foreground process group, attempting to read from > the terminal (even a non-blocking read) will typically suspend the > process (unless you ignore SIGTTIN). And also the fact that the > terminal itself may be line buffered, so the computer has no idea of > what's being typed on it until Return/Enter (or Send, etc) is pressed. Arcane schemes that reflect ancient realities. Unix came about when wasting CPU cycles processing terminal commands was considered extravagant -- CPU cycles were charged to the customers. Nowadays, of course, the CPU processes all keyboard events and commits even more atrocious things like micromanages individual pixels on the screen and encrypts and decrypts all external communication. > [...] > > tl;dr: Unix is not MS-DOS. Thankfully, you don't need to run your program from a terminal. You can interpret keyboard events any way you want if your program is an X11 or Wayland client, and forget all about TTYs, baud rates, parity bits, hangups etc. In fact, that's what emacs does, for example. It can operate in a terminal (and I take advantage of that every day) but I'm typing this in emacs running under X11. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On Wed, Oct 26, 2016 at 8:24 AM, Marko Rauhamaa wrote: > > Thankfully, you don't need to run your program from a terminal. You can > interpret keyboard events any way you want if your program is an X11 or > Wayland client, and forget all about TTYs, baud rates, parity bits, > 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 action, I'm always working in a GUI already, and I can create a menu item with an accelerator. A visible one. Just because you *can* poll the keyboard for events, don't think that you *should*. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 25/10/2016 22:57, Chris Angelico wrote: On Wed, Oct 26, 2016 at 8:24 AM, Marko Rauhamaa wrote: Thankfully, you don't need to run your program from a terminal. You can interpret keyboard events any way you want if your program is an X11 or Wayland client, and forget all about TTYs, 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 into LINE events. What's the difference if we want to concentrate on CHAR or KEY events instead? I've used enough line-buffered editors on teletypes and serial VDUs to remember them as horrible to use. Was the input considered TEXT or KEYBOARD? I can't remember but it wasn't really important. 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. 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 action, I'm always working in a GUI already, and I can create a menu item with an accelerator. A visible one. 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! Just because you *can* poll the keyboard for events, don't think that you *should*. With my rare forays into GUI, that's exactly what I end up doing: in a loop waiting for events. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 which is what > we're talking about) is usually chopped up into LINE events. What's the > difference if we want to concentrate on CHAR or KEY events instead? 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. Of course, you might want to stick your head in the sand and pretend that every character has a button on your keyboard. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
> 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 fundamentally >>> evil, we have to... what? What's so bad about them? Remember, not >>> every program is a server handling myriad clients. >> >> Myriads or not, we are talking about interactive (or reactive) programs. >> The paradigm of choice is event-driven programming. > > Have you watched "Tron"? A program goes to the I/O tower to receive a > message from the User. It's an active operation on the part of the > program. The user cannot initiate it, only the program can. > > Tron is extremely accurate in this way. Thanks for this ChrisA. Rest of this thread has been meh for me, but this one post, definitely won my MostValueablePost for the thread. :) Still chuckling. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 which is what we're talking about) is usually chopped up into LINE events. What's the difference if we want to concentrate on CHAR or KEY events instead? 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 Carriage Return, Backspace and Tab. Of course, you might want to stick your head in the sand and pretend that every character has a button on your keyboard. I'm not sure of the relevance of that. There isn't a 1:1 correspondence between key and character code. So 'a' and 'A' might both be entered by pressing the key marked 'A'. With, possibly, some underlying translation so that the 'A' key can vary locations by locale. That isn't new. It doesn't seem to me that anyone is denying that key-at-a-time access is useful in a wide range of programs. They just seem to be unwilling to let it be it available in a simple, standard form. We are expected to download wxPython first. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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.
>> If you are doing something more complex, waiting on different keys to do
>> different things,
>
> You mean, something as sophisticated as press Enter to continue, or
> Escape to quit? Or Page Up and Page Down?
This discussion is a red herring, because the OP is talking about
non-blocking input. So "Press enter to continue" is not a good model for
what he had in mind.
But regardless, yes, I'd consider using an existing text UI at this point,
rather than try re-inventing the wheel. Unless I *like* re-inventing the
wheel, or that's what I'm being paid for. If I've got two keys to choose
between, I'll probably have more soon:
Page Up, Page Down, Line Up, Line Down, Backwards, Forwards, Refresh, Quit,
Load File, Reload File ...
Somebody once said, there's really only three numbers you need care about.
Zero, one and infinity. Zero is easy to handle -- you don't do anything.
One is easy, because there's only one thing to do. But once you have two
things, you might as well be prepared to handle an indefinitely large
number of things, because you're surely going to need to.
YMMV.
>> then you probably should use an existing text UI like Curses,
>> or a GUI like wxPython etc, rather than trying to reinvent the wheel
>> badly.
>
> 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?
Maybe there is no such lightweight solution? Then that tells you that nobody
else needed this enough to build a solution. Perhaps you're the first!
Congratulations!
Or perhaps you're looking at the question the wrong way. How many thousands
of man-hours, and deaths, came about because people thought that the only
way to fly was by flapping wings like a bird? Maybe there are other ways to
fly... maybe there are other ways to get a good text UI other than
collecting raw keyboard events.
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.
YMMV.
[...]
> This gives you the ability to do (2) above. From that, you could do (1)
> (echoing) and go on to build full line-orientated input. But you had
> complete control.
>
> So, why has it all become so difficult?
Build line oriented input? Why would I do that, when the OS does it?
Okay, sure, if you're programming for some sort of primitive system with no
OS or such a feeble one that it didn't even offer line-oriented text I/O,
then needs must, and you have to do what the OS doesn't provide. But that
sort of low-level I/O is precisely what operating systems are for.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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 Carriage Return, Backspace and Tab. These are called 'control *characters*' because, like characters, they are represented as encoded bytes or, now, as unicode codepoints. 'Home' is not a control character. (I don't know if there is a unicode codepoint for it.) Of course, you might want to stick your head in the sand and pretend that every character has a button on your keyboard. I'm not sure of the relevance of that. There isn't a 1:1 correspondence between key and character code. So 'a' and 'A' might both be entered by pressing the key marked 'A'. With, possibly, some underlying translation so that the 'A' key can vary locations by locale. That isn't new. The translation used to be done by a physically separate terminal and communication between computer and and terminal was via encoded bytes. A program could not access keystrokes because the computer never saw them. Python normally runs in a terminal or console that translates keycodes to encoded bytes It doesn't seem to me that anyone is denying that key-at-a-time access is useful in a wide range of programs. They just seem to be unwilling to let it be it available in a simple, standard form. The simple, standard form for Python, as well as for tcl, perl, and ruby, is as tk events. Python accesses then via tkinter. Other languages have their own version of the API. > We are expected to download wxPython first. Since this is not true, why do you keep repeating it? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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, all while ascii animation was going on. Now it could be that curses forces you into an event-driven paradigm. Not sure about that. But even if it did, your event loop could run a callback that would deposit keystrokes (if any) into another buffer of some kind that your non-event-driven thread could peak into. -- https://mail.python.org/mailman/listinfo/python-list
is it possible use python to run another main point or function in some range of memory in executable file
is it possible python to run another main point or function in some range of memory in executable file -- https://mail.python.org/mailman/listinfo/python-list
Re: how to evaluate a ast tree and change Add to Multiply ?
Hi Jerry, how about custom function? i change to node.op = ast.op2() import ast def op2(a,b): return a*b+a class ChangeAddToMultiply(ast.NodeTransformer): """Wraps all integers in a call to Integer()""" def visit_BinOp(self, node): if isinstance(node.op, ast.Add): node.op = ast.op2() return node code = 'print(2+5)' tree = ast.parse(code) tree = ChangeAddToMultiply().visit(tree) ast.fix_missing_locations(tree) co = compile(tree, '', "exec") exec(code) exec(co) On Thursday, October 20, 2016 at 12:34:55 AM UTC+8, Jerry Hill wrote: > On Wed, Oct 12, 2016 at 5:55 AM, meInvent bbird wrote: > > i just expect to > > rewrite + become multiply > > by edit the example in the link provided > > This seems to work. You need to define visit_BinOp instead of > visit_Num (since you want to mess with the binary operations, not the > numbers). Then,in visit_BinOp, we just replace the ast.Add node with > an ast.Mult node. > > import ast > > class ChangeAddToMultiply(ast.NodeTransformer): > """Wraps all integers in a call to Integer()""" > def visit_BinOp(self, node): > if isinstance(node.op, ast.Add): > node.op = ast.Mult() > return node > > code = 'print(2+5)' > tree = ast.parse(code) > tree = ChangeAddToMultiply().visit(tree) > ast.fix_missing_locations(tree) > co = compile(tree, '', "exec") > > exec(code) > exec(co) > > -- > Jerry -- https://mail.python.org/mailman/listinfo/python-list
UDP decode
Hi! I'm using Kinect with OSCeleton and it is sending the data thru UDP. I can receive it in python, but i can't decode it. I have this: -- import socket UDP_IP = "127.0.0.1" UDP_PORT = 7110 sock = socket.socket(socket.AF_INET, # Internet socket.SOCK_DGRAM) # UDP sock.bind((UDP_IP, UDP_PORT)) while True: data, addr = sock.recvfrom(1024) # buffer size is 1024 bytes print(data) -- And I'm receiving something like this: -- b'/osceleton2/joint\x00\x00\x00,siid\x00\x00\x00head\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x05C\xec\xad&C\xa0\x81vDG\x84N?\x80\x00\x00Bu\x7f\xedh5f\x9b' -- It supouse to be this: -- Address pattern: "/osceleton2/joint" Type tag: "siid" s: Joint name, check out the full list of joints below i: The ID of the sensor i: The ID of the user f: X coordinate of joint in real world coordinates (centimetres) f: Y coordinate of joint in real world coordinates (centimetres) f: Z coordinate of joint in real world coordinates (centimetres) f: confidence value in interval [0.0, 1.0] d: time stamp in milliseconds since Unix epoch example: /osceleton2/joint head 0 1 109.07692 54.557518 666.81543 1. 0. -- Can somebody help me? I worked with OSCeleton in Max/MSP and was fantastic, but here i have this problem. Thanks in advice! OSCeleton: https://github.com/Zillode/OSCeleton-KinectSDK2 -- https://mail.python.org/mailman/listinfo/python-list
Re: UDP decode
On Wed, Oct 26, 2016 at 2:19 PM, wrote: > b'/osceleton2/joint\x00\x00\x00,siid\x00\x00\x00head\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x05C\xec\xad&C\xa0\x81vDG\x84N?\x80\x00\x00Bu\x7f\xedh5f\x9b' > -- > > > It supouse to be this: > -- > Address pattern: "/osceleton2/joint" > Type tag: "siid" > s: Joint name, check out the full list of joints below > i: The ID of the sensor > i: The ID of the user > f: X coordinate of joint in real world coordinates (centimetres) > f: Y coordinate of joint in real world coordinates (centimetres) > f: Z coordinate of joint in real world coordinates (centimetres) > f: confidence value in interval [0.0, 1.0] > d: time stamp in milliseconds since Unix epoch > > example: > > /osceleton2/joint head 0 1 109.07692 54.557518 666.81543 1. 0. Well, the first bit clearly matches. Then you have four bytes ending with a comma (0x2C) and then siid. A few more NULs and "head". So really, the interesting part starts after that. Can you find information you recognize in any of the bytes that follow that? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
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, CPython, nethack etc "solve the problem" by setting the terminal mode. You can, too: https://docs.python.org/3/library/termios.html https://docs.python.org/3/library/tty.html However, that only gives you access to the interpreted characters. For example, you can't see when a [Shift] key has been pressed. > 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 consider that to be very low level. If you want to get to the low level, open /dev/input/by-id/*-event-kbd See: http://stackoverflow.com/questions/3662368/dev-input-keyboard-format Marko -- https://mail.python.org/mailman/listinfo/python-list
