poll(timeout, max_ev)
KeyboardInterrupt
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python3.6/concurrent/futures/thread.py", line 40, in
_python_exit
t.join()
File "/usr/lib/python3.6/threading.py", line 1056, in join
self._wait_for_
MOn Tue, Nov 19, 2013 at 10:35 AM, Jai
wrote:
> please help what is this i have try lot but unable to remove it
Your code is getting into an infinite loop.
One problem is, I suspect:
> def find_position(line):
> pun = ""
> if re.search(r"[.?!]+", line):
> pun = re.search(r"[.?!]
ility of .9 it isn't. The
result should be:
Mr. Smith bought example. cheapsite. com for 1. 5 million dollars, i. e. he
paid a lot for it.
Did he mind?
Adam Jones Jr. thinks he didn't.
In any case, this isn't true...
Well, with a probability of . 9 it isn't.
#
e didn't.
In any case, this isn't true... Well, with a probability of .9 it isn't. The
result should be:
Mr. Smith bought example. cheapsite. com for 1. 5 million dollars, i. e. he
paid a lot for it.
Did he mind?
Adam Jones Jr. thinks he didn't.
In any case, this isn&
All:
I am maintaining a program in Python 2 and need to send it a
KeyboardInterrupt to close it. Unfortunately, the program is used as a
subprocess in a wrapper subprocess, and so I cannot just directly press
CTL-C; I have to use a signal.
When I run the program "bare" (not in a subp
Hi,
I was wondering which approach is better to stop several servers from
just on python application when 'ctrl-c' is pressed, a try/except
KeyboardInterrupt or just registering a SIGINT handler and exit when the
signal is triggered. Any advantage/disadvantage from one approach
Am 09.05.2010 11:59, schrieb Lawrence D'Oliveiro:
In message,
exar...@twistedmatrix.com wrote:
On 07:48 am, l...@geek-central.gen.new_zealand wrote:
In message,
exar...@twistedmatrix.com wrote:
This is a good example of why it's a bad idea to use select on
Windows.
Instead, use WaitForMulti
In message ,
exar...@twistedmatrix.com wrote:
> On 07:48 am, l...@geek-central.gen.new_zealand wrote:
>
>>In message ,
>>exar...@twistedmatrix.com wrote:
>>
>>>This is a good example of why it's a bad idea to use select on
>>>Windows.
>>>Instead, use WaitForMultipleObjects.
>>
>>How are you suppo
2010/5/8 Antoine Pitrou :
> On Sat, 8 May 2010 13:47:53 +0200
> Giampaolo Rodolà wrote:
>>
>> Assuming loop() function does something like this:
>>
>> ...
>> select.select(r, w, e, timeout)
>> scheduler() # checks for scheduled calls to be fired
>> ...
>>
>> ...imagine a case
On 11:47 am, g.rod...@gmail.com wrote:
2010/5/7 Antoine Pitrou :
Le Fri, 07 May 2010 21:55:15 +0200, Giampaolo Rodol� a �crit�:
Of course, but 30 seconds look a little bit too much to me, also
because
(I might be wrong here) I noticed that a smaller timeout seems to
result
in better performan
On 07:48 am, l...@geek-central.gen.new_zealand wrote:
In message ,
exar...@twistedmatrix.com wrote:
This is a good example of why it's a bad idea to use select on
Windows.
Instead, use WaitForMultipleObjects.
How are you supposed to write portable code, then?
With WaitForMultipleObjects on
On Sat, 8 May 2010 13:47:53 +0200
Giampaolo Rodolà wrote:
>
> Assuming loop() function does something like this:
>
> ...
> select.select(r, w, e, timeout)
> scheduler() # checks for scheduled calls to be fired
> ...
>
> ...imagine a case where there's a connection (aka a di
2010/5/7 Antoine Pitrou :
> Le Fri, 07 May 2010 21:55:15 +0200, Giampaolo Rodolà a écrit :
>> Of course, but 30 seconds look a little bit too much to me, also because
>> (I might be wrong here) I noticed that a smaller timeout seems to result
>> in better performances.
>
> That's probably bogus.
P
In message ,
exar...@twistedmatrix.com wrote:
> This is a good example of why it's a bad idea to use select on Windows.
> Instead, use WaitForMultipleObjects.
How are you supposed to write portable code, then?
--
http://mail.python.org/mailman/listinfo/python-list
On 7 May, 07:25 pm, p.f.mo...@gmail.com wrote:
On 7 May 2010 15:36, Giampaolo Rodol� wrote:
You can easily avoid this by setting a lower timeout when calling
asyncore.loop(), like 1 second or less (for example, Twisted uses
0.001 secs).
Thanks, that's what I was considering.
This is a good
Le Fri, 07 May 2010 21:55:15 +0200, Giampaolo Rodolà a écrit :
> Of course, but 30 seconds look a little bit too much to me, also because
> (I might be wrong here) I noticed that a smaller timeout seems to result
> in better performances.
That's probably bogus.
> Plus, if scheduled callbacks are
2010/5/7 Antoine Pitrou :
> Le Fri, 07 May 2010 16:36:44 +0200, Giampaolo Rodolà a écrit :
>> You can easily avoid this by setting a lower timeout when calling
>> asyncore.loop(), like 1 second or less (for example, Twisted uses 0.001
>> secs).
>> Actually there's no reason for asyncore to have suc
On 7 May 2010 15:36, Giampaolo Rodolà wrote:
> You can easily avoid this by setting a lower timeout when calling
> asyncore.loop(), like 1 second or less (for example, Twisted uses
> 0.001 secs).
Thanks, that's what I was considering.
> Actually there's no reason for asyncore to have such a high
Le Fri, 07 May 2010 16:36:44 +0200, Giampaolo Rodolà a écrit :
> You can easily avoid this by setting a lower timeout when calling
> asyncore.loop(), like 1 second or less (for example, Twisted uses 0.001
> secs).
> Actually there's no reason for asyncore to have such a high default
> timeout (30 s
.socket()
> select.select([s], [], [], 30)
>
> and then press Ctrl-C, Python waits for the 30 seconds before raising
> KeyboardInterrupt.
>
> Is this a known limitation on Windows? I see no mention of it in the
> documentation. Assuming it is a known limitation, is there a
On 6 May, 20:58, Thomas Heller wrote:
> If you look at the source code for time.sleep(), which CAN be interrupted
> by pressing Ctrl-C, you will find that it is carefully programmed to be
> interruptible (sp?). Which is not the case for select.select(), obviously.
Thanks - given this, would it b
Python waits for the 30 seconds before raising
> KeyboardInterrupt.
>
> Is this a known limitation on Windows? I see no mention of it in the
> documentation. Assuming it is a known limitation, is there a way round
> it? (I'm writing a tiny server using asyncore/asynchat, and
>From a quick experiment, it seems that select.select with a timeout
doesn't react to a keyboard interrupt until the timeout expires.
Specifically, if I do
s = socket.socket()
select.select([s], [], [], 30)
and then press Ctrl-C, Python waits for the 30 seconds before raising
KeyboardI
DiskIO appears to not be interruptable. For example:
>>> open('bighugefile.sql').read()
Pressing Ctrl-C (on Linux with python 2.6.4) will not interrupt the
command. I believe that it used to in previous versions of python but
I may be mistaken. Is it supposed to be that way? The behavior is
annoy
En Thu, 10 Dec 2009 20:43:48 -0300, mattia escribió:
Il Thu, 10 Dec 2009 23:10:02 +, Matthew Barnett ha scritto:
Only the main thread can receive the keyboard interrupt.
Ok, so is there any way to stop all the threads if the keyboard interrupt
is received?
If all other threads (except
running = any(t.is_alive() for t in threads)
except KeyboardInterrupt:
running = False
--
http://mail.python.org/mailman/listinfo/python-list
Il Wed, 09 Dec 2009 16:19:24 -0800, Jon Clements ha scritto:
> On Dec 9, 11:53 pm, mattia wrote:
>> Hi all, can you provide me a simple code snippet to interrupt the
>> execution of my program catching the KeyboardInterrupt signal?
>>
>> Thanks,
>> Mattia
>
On Dec 9, 11:53 pm, mattia wrote:
> Hi all, can you provide me a simple code snippet to interrupt the
> execution of my program catching the KeyboardInterrupt signal?
>
> Thanks,
> Mattia
Errr, normally you can just catch the KeyboardInterrupt exception --
is that what you mean?
ements ha scritto:
>>>>
>>>>> On Dec 9, 11:53 pm, mattia wrote:
>>>>>> Hi all, can you provide me a simple code snippet to interrupt the
>>>>>> execution of my program catching the KeyboardInterrupt signal?
>>>>>>
>&
execution of my program catching the KeyboardInterrupt signal?
Thanks,
Mattia
Errr, normally you can just catch the KeyboardInterrupt exception --
is that what you mean?
Jon.
Ouch, so the simplest solution is just insert in the 'main' function a
try/catch? I believed there was the ne
On Thu, Dec 10, 2009 at 4:42 PM, mattia wrote:
> def go():
>threads = [Thread(target=do_work, args=()) for _ in range(2)]
>for t in threads:
>t.start()
>for t in threads:
> t.join()
>
The KeyboardInterrupt goes to the main thread, which is si
a simple code snippet to interrupt the
>>>> execution of my program catching the KeyboardInterrupt signal?
>>>>
>>>> Thanks,
>>>> Mattia
>>>
>>> Errr, normally you can just catch the KeyboardInterrupt exception --
>>> is that
On Thu, 10 Dec 2009 00:29:45 +, mattia wrote:
> Il Wed, 09 Dec 2009 16:19:24 -0800, Jon Clements ha scritto:
>
>> On Dec 9, 11:53 pm, mattia wrote:
>>> Hi all, can you provide me a simple code snippet to interrupt the
>>> execution of my program catchin
on.
For C code, the solution you give sounds like a
good one.
My only misgiving is that the user might expect to
get a KeyboardInterrupt in response to Ctrl-C, so
it might be better to just let it propagate instead
of turning it into a different exception.
I completely agree. The simple solution (
ike a
good one.
My only misgiving is that the user might expect to
get a KeyboardInterrupt in response to Ctrl-C, so
it might be better to just let it propagate instead
of turning it into a different exception.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
is KeyboardInterrupt, not the special
exception from the IPC module.
So I looked in the source code how they did it:
The code is in Parser/myreadline.c.
This code for input in function calls PyErr_CheckSignals() and
PyOS_InterruptOccurred() for a proper handling of the interrupt. So it
seems the
After my previous experiment I was curious how this works with
input(). I replaced the sem.acquire() with raw_input() and ran the same
tests. Now the inner exception is really taken so it works like the OP
expected. The exception, however is KeyboardInterrupt, not the special
exception from the
>>>>> greg (g) wrote:
>g> Philip Semanchuk wrote:
>>> try:
>>> sem.acquire() # User hits Ctrl + C while this is waiting
>>> except:
>>> print "* I caught it!"
>>> Instead a KeyboardInterrupt error is propaga
Philip Semanchuk wrote:
try:
sem.acquire() # User hits Ctrl + C while this is waiting
except:
print "* I caught it!"
Instead a KeyboardInterrupt error is propagated up to the interpreter
and the process is killed as if the try/except wasn't there at all.
N
signal.
However, the caller never sees the error I set. Instead they get a
KeyboardInterrupt that refuses to be caught by try/except. Here's a
sample program that demonstrates the problem when run from the command
line:
# ---
import posix_ipc
it's time waiting for a separate non-Python subprocess (created
> with subprocess.Popen) to finish anyway. (I guess Python would see
> this as IO-blocking) Therefore, if you can fix my toy example with
> threading, that's fine.
>
> DB.py, followed by a KeyboardInterr
ted
with subprocess.Popen) to finish anyway. (I guess Python would see
this as IO-blocking) Therefore, if you can fix my toy example with
threading, that's fine.
DB.py, followed by a KeyboardInterrupt yields the output in a.out. I
want roughly the output in desired.out.
What do I need
On Mon, 15 Jun 2009 05:37:14 -0700 (PDT)
OdarR wrote:
> On 13 juin, 07:25, Mike Kazantsev wrote:
> > There was quite interesting explaination of what happens when you send
> > ^C with threads, posted on concurrency-sig list recently:
> >
> > http://blip.tv/file/2232410
> > http://www.dabeaz.co
On 13 juin, 07:25, Mike Kazantsev wrote:
> There was quite interesting explaination of what happens when you send
> ^C with threads, posted on concurrency-sig list recently:
>
> http://blip.tv/file/2232410
> http://www.dabeaz.com/python/GIL.pdf
>
> Can be quite shocking, but my experience w/ thr
In article ,
Dennis Lee Bieber wrote:
>
> As for the use of X-Noarchive headers... Back before Google, most
>NNTP servers had automatic expiration of messages (on my ISP at the
>time, the binary groups expired after 24 hours!, most messages expired
>after one or two weeks). I never used X-N
On Sat, 13 Jun 2009 04:42:16 -0700 (PDT)
koranthala wrote:
> Are there other videos/audio like this? I am learning more from these
> videos than by experience alone.
Indeed, it is a very interesting presentation, but I'm afraid I've
stumbled upon it just as you did, but on concurrency-sig mailin
n will get interrupt.
>
>
>
> > > def runAll():
> > > workers = [ Thread(target = runSingle, args = [i])
> > > for i in xrange(MAX_SUBPROCS + 1) ]
> > > try:
> > > for w in workers:
> > > w.start()
> > >
surance that any thread other than
> the main program will receive a keyboard interrupt.
In fact, no thread other than the main will get interrupt.
> > def runAll():
> > workers = [ Thread(target = runSingle, args = [i])
> > for i in xrange(MAX_SUBPROCS
On Jun 12, 3:35 pm, Dennis Lee Bieber wrote:
> On Thu, 11 Jun 2009 08:44:24 -0500, "Strax-Haber, Matthew (LARC-D320)"
> declaimed the following in
> gmane.comp.python.general:
>
> > I sent this to the Tutor mailing list and did not receive a response.
> > Perhaps one of you might be able to offer
Reply-To: Matthew Strax-Haber
> Date: Tue, 9 Jun 2009 22:01:33 -0500
> To: Python Tutor
> Subject: [Tutor] Multi-Threading and KeyboardInterrupt
>
> Hey everyone,
>
> I hope one of you can help me with this. This is my first foray into
> multi-threaded programming. I h
Gabriel Genellina wrote:
En Sat, 16 May 2009 04:04:03 -0300, Igor Katson
escribió:
Gabriel Genellina wrote:
En Fri, 15 May 2009 09:04:05 -0300, Igor Katson escribió:
Lawrence D'Oliveiro wrote:
In message ,
Igor Katson wrote:
Lawrence D'Oliveiro wrote:
In message ,
Igor Katson wrote:
I h
er server_forever exited, shutdown() blocks forever.
from SocketServer import TCPServer, BaseRequestHandler
from threading import Thread
server = TCPServer(('localhost',1234), BaseRequestHandler)
run_thread = Thread(target=server.serve_forever)
run_thread.start()
try:
print "
er
server = TCPServer(('localhost',1234), BaseRequestHandler)
try:
server.serve_forever()
except KeyboardInterrupt:
print "^C detected"
pass
finally:
print "server_close()"
server.server_close()
print "bye"
(I've opened ht
er
server = TCPServer(('localhost',1234), BaseRequestHandler)
try:
server.serve_forever()
except KeyboardInterrupt:
print "^C detected"
pass
finally:
print "server_close()"
server.server_close()
print "bye"
(I've opened ht
7;localhost',1234), BaseRequestHandler)
try:
server.serve_forever()
except KeyboardInterrupt:
print "^C detected"
pass
finally:
print "server_close()"
server.server_close()
print "bye"
(I've opened http://bugs.python.org/issue6031 )
Lawrence D'Oliveiro wrote:
In message , Igor Katson
wrote:
Lawrence D'Oliveiro wrote:
In message , Igor
Katson wrote:
I have problems in getting a SocketServer to shutdown.
Do you want to do a shutdown or a close?
I want the server close the socket ...
In message , Igor Katson
wrote:
> Lawrence D'Oliveiro wrote:
>
>> In message , Igor
>> Katson wrote:
>>
>>> I have problems in getting a SocketServer to shutdown.
>>
>> Do you want to do a shutdown or a close?
>>
> I want the server close the socket ...
You want to do a close, do a close,
Lawrence D'Oliveiro wrote:
In message , Igor Katson
wrote:
I have problems in getting a SocketServer to shutdown.
Do you want to do a shutdown or a close?
I want the server close the socket, and the program to continue after
that (in this case, just to terminate).
--
http://mai
In message , Igor Katson
wrote:
> I have problems in getting a SocketServer to shutdown.
Do you want to do a shutdown or a close?
--
http://mail.python.org/mailman/listinfo/python-list
I have problems in getting a SocketServer to shutdown. Why does this not
actually stop the application?
from SocketServer import UnixStreamServer, BaseRequestHandler
server = UnixStreamServer('/tmp/ss.sock', BaseRequestHandler)
try:
server.serve_forever()
except Keyboar
On Jun 19, 11:09 pm, Brendon Costa <[EMAIL PROTECTED]> wrote:
> > If only the main thread can receive KeyboardInterrupt, is there any
> > reason why you couldn't move the functionality of the Read thread into
> > the main thread? It looks like it's not doing any w
> If only the main thread can receive KeyboardInterrupt, is there any
> reason why you couldn't move the functionality of the Read thread into
> the main thread? It looks like it's not doing any work, just waiting
> for the Proc thread to finish.
>
> You could start the
t included a
> "die" object and "write" to that object to break the blocking wait.
>
> If your blocking call has no time-out variant, you may be stuck...
>
If only the main thread can receive KeyboardInterrupt, is there any
reason why you couldn't move the f
I tested this a bit more. My windows example was incorrect. It should
have used CTRL_C_EVENT. But even then, the problem is that the process
will also close the console window from which it was called because of
the 0. Also this requires that the process actually have a console and
is not a GUI app
I tested this a bit more. My windows example was incorrect. It should
have used CTRL_C_EVENT. But even then, the problem is that the process
will also close the console window from which it was called because of
the 0. Also this requires that the process actually have a console and
is not a GUI app
he
> Python C API) to inject a KeyboardInterrupt exception into the Read thread
> - but I don't know if it will work at all, the execution might be blocked
> waiting for an I/O call to complete, and never return to Python code...
>
Unfortunately that is the problem. It is blocking in a IO syste
hat is the standard/best way of implementing
such a pattern that works in the presence of errors and particularly
with the KeyboardInterrupt exception?"
I don't know the "standard" way, but perhaps you can get some ideas from
this recent thread:
http://groups.google.com/group/com
f errors and particularly
with the KeyboardInterrupt exception?"
Some sample code is shown below. This code works as is, except in the
case where the "Proc" thread wants to initiate the exit of the
application.
For example:
* running the code below and pressing Ctrl + C works f
hread):
> def __init__(self):
> super(MyThread, self).__init__()
> self.start()
>
> def run(self):
> while True:
> try:
> time.sleep(10)
>
t()
def run(self):
while True:
try:
time.sleep(10)
except KeyboardInterrupt:
print 'thread keyboard interrupt'
def main():
my = MyThread()
In article <[EMAIL PROTECTED]>,
Michael Goerz <[EMAIL PROTECTED]> wrote:
> But as it seems, a keyboard interrupt will automatically pass down to
> the subprocesses, causing them to abort. Is there a way that I can
> prevent the subprocesses from being canceled by a keyboard interrupt?
You mi
nother dummy program if it isn't
p = subprocess.Popen(['sleep', '10'])
while True:
try:
time.sleep(1)
pass # normal program procedure
print "subprocess poll: " + str(p.poll())
except KeyboardInterrupt:
En Mon, 04 Feb 2008 11:53:52 -0200, Michael Goerz
<[EMAIL PROTECTED]> escribi�:
> when I try to catch ctrl+c with
>
> except KeyboardInterrupt:
>
> pychecker tells me
>
> Catching a non-Exception object (KeyboardInterrupt)
>
> It works fine, but the message i
Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Michael Goerz <[EMAIL PROTECTED]> writes:
>
>> when I try to catch ctrl+c with
>>
>> except KeyboardInterrupt:
>>
>> pychecker tells me
>>
>> Catching a non-Exception object (KeyboardInterrup
Michael Goerz <[EMAIL PROTECTED]> writes:
> when I try to catch ctrl+c with
>
> except KeyboardInterrupt:
>
> pychecker tells me
>
> Catching a non-Exception object (KeyboardInterrupt)
Looks like a pychecker bug. It might be confused by KeyboardInterrupt
being deri
Hi,
when I try to catch ctrl+c with
except KeyboardInterrupt:
pychecker tells me
Catching a non-Exception object (KeyboardInterrupt)
It works fine, but the message indicates that it's not completely clean.
How should I write the exception correctly?
Thanks,
Michael
--
On 16 Feb., 12:16, [EMAIL PROTECTED] wrote:
> On 16 Feb., 11:44, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
>
> I've tried it in cygwin, result:
$ python.exe c:/work/py_src/ctrl_test.py
kbd-interr,SystemExit
normal end
br Rudi
--
http://mail.python.org/mailman/listinfo/python-list
On 16 Feb., 11:44, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
Thanks to all of you, for the fast answers.
The code I showed you is actually the code running. I tried to catch
eof, cause I read ^C could produce EOF (the self.showtraceback() was
just a stupid cut 'n paste). But not even the exce
En Fri, 16 Feb 2007 07:26:09 -0300, Steven D'Aprano
<[EMAIL PROTECTED]> escribió:
> I seem to have a vague recollection that the keyboard interrupt under
> Windows isn't ^C but something else... ^Z maybe?
Ctrl-C is the keyboard interrupt, Ctrl-Z means EOF.
--
Gabriel Genellina
--
http://mai
On Fri, 16 Feb 2007 01:47:43 -0800, ruka_at_ wrote:
> Hi,
> why is KeyboardInterrupt not caught (xp)?
> import sys
> try:
> inp = sys.stdin.read()
> except (KeyboardInterrupt, SystemExit):
> print "kbd-interr,SystemExit"
> except EOFError:
> print
En Fri, 16 Feb 2007 06:58:54 -0300, Daniel Nogradi <[EMAIL PROTECTED]>
escribió:
>> why is KeyboardInterrupt not caught (xp)?
>
> Hi, are you sure this is exactly what you run?
> The code above works perfectly for me and prints
>
> kbd-interr,SystemExit
> no
> why is KeyboardInterrupt not caught (xp)?
> import sys
> try:
> inp = sys.stdin.read()
> except (KeyboardInterrupt, SystemExit):
> print "kbd-interr,SystemExit"
> except EOFError:
> print "eof encountered"
> except:
> print "
Hi,
why is KeyboardInterrupt not caught (xp)?
import sys
try:
inp = sys.stdin.read()
except (KeyboardInterrupt, SystemExit):
print "kbd-interr,SystemExit"
except EOFError:
print "eof encountered"
except:
print "caught all"
self.showtraceback()
pr
I see. So if I get that right, that would mean that if I, in my
function, would loop and retry when getting an EINTR instead of
returning, a KeyboardInterrupt from e.g. Ctrl-C would be delayed until
it has other reason to return?
Thanks for your answer!
Fredrik Tolf
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Tolf wrote:
> So how does it work? Does my code get to return Py_FALSE, and the
> interpreter ignores it, seeing that an exception is set? Is a non-local
> exit performed right over my call stack (in which case my next question
> would be how to clean up resources being used from my C code
Dear List,
I was writing a Python extension module, including a sleeping call to
poll(2), and noticed, to my great surprise (and joy), that even when
blocking there, KeyboardInterrupt still worked properly when sending
SIGINTs to the interpreter. It really got me wondering how it works,
though
In article <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> if you want to interrupt the code to find out where it is,
> you can instead connect to it in gdb and get the python traceback of
> each thread.
> if you're interested I'll post the necesary gdb-macro for that (didn'
if you want to interrupt the code to find out where it is,
you can instead connect to it in gdb and get the python traceback of
each thread.
if you're interested I'll post the necesary gdb-macro for that (didn't
put it on the net yet)
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tony Nelson wrote:
> > I'm trying to find out what is eating some KeyboardInterrupt exceptions
> > in a fairly large program (yum). My KeyboardInterrupt handler is called
> > for some Ctl-C presses,
Tony Nelson wrote:
> I'm trying to find out what is eating some KeyboardInterrupt exceptions
> in a fairly large program (yum). My KeyboardInterrupt handler is called
> for some Ctl-C presses, but for others nothing seems to happen.
> ... I'd like to use a debugger to tra
I'm trying to find out what is eating some KeyboardInterrupt exceptions
in a fairly large program (yum). My KeyboardInterrupt handler is called
for some Ctl-C presses, but for others nothing seems to happen.
Grepping the source (what of it I've found, looking at import
statement
Indeed, I did the experiment again with
while 1:
y = os.system("sleep 1")
print y
and it ALWAYS returns 0, with control-c or without.
>From past experience, I am pretty sure that in other cases I have been
getting non-zero return values. So I would hesitate to believe that
what you observe i
Thanks for the tips everyone, although it turns out this is not a python
problem at all. After several tests with mpg123 both direct on the cli, and
wrapped in an os.system() call, I see it is _always_ returning 0 exit status
whether I interrupt it or not. I went to the mpg123 website to see if
In article <[EMAIL PROTECTED]>,
"malv" <[EMAIL PROTECTED]> wrote:
> That's also kind of what I expected.
> However, I quickly tried:
> import os
> while 1:
> y = os.system("sleep 1")
> z = (y >> 8) & 0xFF
> print z
>
> I never get anything in return but 0, hitting c-C or not.
> I h
That's also kind of what I expected.
However, I quickly tried:
import os
while 1:
y = os.system("sleep 1")
z = (y >> 8) & 0xFF
print z
I never get anything in return but 0, hitting c-C or not.
I have uset the above code to get exit code returns in the past though.
Would there be any
[EMAIL PROTECTED] wrote:
> You can tell by the exit code from system() whether the subprocess
> exited due to a signal. Consider this code:
> import os
> while 1:
> print os.system("sleep 1")
> unless you happen to hit ctrl-c at the right time, you'll see it print
> "2" (and "0" wh
You can tell by the exit code from system() whether the subprocess
exited due to a signal. Consider this code:
import os
while 1:
print os.system("sleep 1")
unless you happen to hit ctrl-c at the right time, you'll see it print
"2" (and "0" when the sleep finishes). The exit code
d exit (somewhat) gracefully if the
> user decides to abort the program. I am using os.system for the system call,
> and I have wrapped the entire main loop in a try: except KeyboardInterrupt
> statement to try to attain these ends.
>
> As it is though, if the program is curren
abort the program. I am using os.system for the system call,
and I have wrapped the entire main loop in a try: except KeyboardInterrupt
statement to try to attain these ends.
As it is though, if the program is currently in the system command, only that
system command is terminated, and the next
except the fact
>> that if, for example, I start computing the diameter of a random graph
>> of ~10 nodes and ~20 edges, I can't cancel it, because the
>> KeyboardInterrupt is not propagated to the Python toplevel (or it isn't
>> even generated until the igraph li
1 - 100 of 108 matches
Mail list logo
