By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,587 Members | 1,692 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,587 IT Pros & Developers. It's quick & easy.

Python sleep doesn't work right in a loop?

P: n/a
Just a simple bit of code to toggle between two state at intervals...

import time
for i in range(4):
print 'On'
time.sleep(1)
print 'Off'
time.sleep(1)

.... SHOULD toggle On and Off four times with one-second pauses. When I
run this, the loop pauses the full eight seconds then prints the Ons
and Offs all at once. What's up with that?

Jul 18 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
For me it works fine. It seems that for you stdout is not flushed
correctly in your terminal. What kind of terminal are you writing to?

Jul 18 '05 #2

P: n/a
ri********@yahoo.com wrote:
Just a simple bit of code to toggle between two state at intervals...

import time
for i in range(4):
print 'On'
time.sleep(1)
print 'Off'
time.sleep(1)

... SHOULD toggle On and Off four times with one-second pauses. When I
run this, the loop pauses the full eight seconds then prints the Ons
and Offs all at once. What's up with that?


Works for me - on a terminal using linux. BUT what not works is this:

python /tmp/test.py | cat

(test.py contains your code of course) The reason is buffered pipes being
used. Try this:

import time, sys
for i in range(4):
print 'On'
sys.stdout.flush()
time.sleep(1)
print 'Off'
sys.stdout.flush()
time.sleep(1)

--
Regards,

Diez B. Roggisch
Jul 18 '05 #3

P: n/a
ri********@yahoo.com wrote:
... SHOULD toggle On and Off four times with one-second pauses. When I
run this, the loop pauses the full eight seconds then prints the Ons
and Offs all at once. What's up with that?


Run your script as:

python -u script.py

for unbuffered output.

Jul 18 '05 #4

P: n/a
This is running in the interactive 'PyShell', but in truth those print
statements are part of a gui app that flashes a control in wx.widgets
by toggling it's background color. The same behavior either way.

Jul 18 '05 #5

P: n/a
Nope. Does't work. Running Python 2.3.4 on Debian, Linux kernel 2.6.
This is actually test code for a larger project...

# flash the selected wx.TextControl

for flasher in range(4):
self.textField.SetBackgroundColour(255, 0, 0)
time.sleep(0.8)
self.textField.SetBackgroundColour(255, 255, 223)
time.sleep(0.8)

Even when I add an explicit call to repaint the TextCtrl between each
sleep, things appear to be 'queued' until after the loop is fnished.
Very bizarre.

Jul 18 '05 #6

P: n/a
ri********@yahoo.com wrote:
Nope. Does't work. Running Python 2.3.4 on Debian, Linux kernel 2.6.
This is actually test code for a larger project...

# flash the selected wx.TextControl

for flasher in range(4):
self.textField.SetBackgroundColour(255, 0, 0) self.textField.Update() time.sleep(0.8)
self.textField.SetBackgroundColour(255, 255, 223) self.textField.Update() time.sleep(0.8)

Even when I add an explicit call to repaint the TextCtrl between each
sleep, things appear to be 'queued' until after the loop is fnished.
Very bizarre.


If you use .Refresh() request still queued.

/m

Jul 18 '05 #7

P: n/a
ri********@yahoo.com wrote:
Nope. Does't work. Running Python 2.3.4 on Debian, Linux kernel 2.6.
This is actually test code for a larger project...

# flash the selected wx.TextControl

for flasher in range(4):
self.textField.SetBackgroundColour(255, 0, 0)
time.sleep(0.8)
self.textField.SetBackgroundColour(255, 255, 223)
time.sleep(0.8)

Even when I add an explicit call to repaint the TextCtrl between each
sleep, things appear to be 'queued' until after the loop is fnished.
Very bizarre.

Not at all, but completely unrelated to your initial question.

You need to use a specific call before each sleep to tell wxPython to
update the display, since the sleep doesn't give control back to the
display subsystem. I think the call you need is app.Yield(), but the
docs will confirm that.

regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 18 '05 #8

P: n/a
Nope. Does't work. Running Python 2.3.4 on Debian, Linux kernel 2.6.
This is actually test code for a larger project...
No Nope - it _does_ work. Did you actually try it? Because you use it in a
wrong context does not mean that it doesn't work. Besides, giving a wrong
example to prove a point is always a bad idea.
# flash the selected wx.TextControl

for flasher in range(4):
self.textField.SetBackgroundColour(255, 0, 0)
time.sleep(0.8)
self.textField.SetBackgroundColour(255, 255, 223)
time.sleep(0.8)

Even when I add an explicit call to repaint the TextCtrl between each
sleep, things appear to be 'queued' until after the loop is fnished.
Very bizarre.


That's a totally different thing - no idea how wx works in detail, but the
behaviour you describe looks as if the calls to SetBackgroundColour are
queued until the event loop is processed again. So check how to do that
manually between calls, and things are most probably working.

Again - giving the above example would made us give you that advice way
earlier - and saved us digging in the wrong direction...

--
Regards,

Diez B. Roggisch
Jul 18 '05 #9

P: n/a
Actually, I've tried ALL of these things, and none of them work. I HAVE
run the simple for-print-sleep test code to try to determine if this
issue was specific to wx (that's good troubleshooting, folks - you
narrow down the problem) and even that didn't work, so I thought I'd
start with the simple problem first. Sorry if you were mislead.

As for wx, I HAVE used the for-setColour-refresh-update-sleep loop,
still no dice. The last thing the I put in the loop works (again, as if
all the changes are being queued) but the sleep just 'takes over' the
loop and nothing happens until al the sleeps are done. With or without
wx. Not good.

Jul 18 '05 #10

P: n/a
ri********@yahoo.com wrote:
Actually, I've tried ALL of these things, and none of them work. I HAVE
run the simple for-print-sleep test code to try to determine if this
issue was specific to wx (that's good troubleshooting, folks - you
narrow down the problem) and even that didn't work, so I thought I'd
start with the simple problem first. Sorry if you were mislead.
But it _is_ no problem - the code you gave us works for me and others as
expected - on a very similar system, btw. So there _is_ a difference - do
you call the script from an ide, pipe it or something similar?

And as you yourself found that 4 time.sleep(2) produce 8 seconds timeout in
total, it is pretty obvious that the problem is _not_ time.sleep - but that
whatever effect you want to produce between the calls is not happening. For
the print, we gave you some suggestions.
As for wx, I HAVE used the for-setColour-refresh-update-sleep loop,
still no dice. The last thing the I put in the loop works (again, as if
all the changes are being queued) but the sleep just 'takes over' the
loop and nothing happens until al the sleeps are done. With or without
wx. Not good.


certainly not good - maybe you should read this

http://fraca7.free.fr/blog/index.php...ord-about-guis

One quote from the comments:

'''
I am working on a major project, using Python+Twisted. I started using
wxPython for the GUI, then discovered that it was completely unuseable. The
wxWidgets event loop is hidden away, and the only way Twisted can integrate
(the reactor) is to set a timer and run for a few cycles every so often.
The resulting app does not paint properly, has huge lags, and is basically
useless. I rewrote it using PyGtk and the GUI is nice and smooth, thanks to
the flexible event loop design. I am not likely to use wxWidgets again,
I've had many stability problems with it under both Linux and Mac, and the
current stable version doesn't even support the latest Gtk.
So that's my rant too I guess, agree with all you wrote above.
'''

If you can live without windows compatibility - or wait for qt4 - and the
GPL, I suggest a switch to qt.

Sleep does not "takeover" a loop - there is no semantics defined for that.
Try putting the flushes after the prints, and you'll see things work. What
wx influences are on this I can't say - but the quote above suggests that
event handling is not as straight in wx as it should be.

--
Regards,

Diez B. Roggisch
Jul 18 '05 #11

P: n/a
On Wed, 06 Apr 2005 12:49:51 -0700, ritterhaus wrote:
Nope. Does't work. Running Python 2.3.4 on Debian, Linux kernel 2.6. This
is actually test code for a larger project...

# flash the selected wx.TextControl

for flasher in range(4):
self.textField.SetBackgroundColour(255, 0, 0) time.sleep(0.8)
self.textField.SetBackgroundColour(255, 255, 223) time.sleep(0.8)

Even when I add an explicit call to repaint the TextCtrl between each
sleep, things appear to be 'queued' until after the loop is fnished. Very
bizarre.


GUIs don't like "time.sleep". All of them come with some sort of "fire a
timing event in X milliseconds and call this handler". Use that instead.

I believe wx's is the wxTimer class, and the wxFutureCall class looks
promising.

If you want to maintain the same basic calling structure, start playing
games with generators; you can write the same function with "yield", and
then call .next() on an iterator every time the timeout triggers. Best of
both worlds.

Jul 18 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.