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 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:
>
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
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):
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
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
animati
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 which is wh
> 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 which is what
> we're talking about) is usu
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 rate
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 st
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 gra
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
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
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{
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
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', passwo
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'
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=
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 few months a
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 th
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
myself. T
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
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
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 (
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
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 be
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
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 thi
40 matches
Mail list logo
