how to call a function for evry 10 secs

[hisan]

Hi All,
I need to call a function for evry 10 secs
how can i achieve this in python

 

[Steven D'Aprano]

Hi All,
I need to call a function for evry 10 secs
how can i achieve this in python

import time
while True:
time.sleep(10)
function()

 

[Dennis Lee Bieber]

Hi All,
I need to call a function for evry 10 secs
how can i achieve this in python

Do you mean you need a 10 second delay BETWEEN each call of the
function? OR do you mean the function must be called every 10 seconds
(as long as the function completes in less than 10 seconds).

The first is the simple one that's no doubt been shown already
.... print t
.... time.sleep(5)
........ dumpTime(time.clock())
.... time.sleep(10)
....
68.0374675818
83.0283211852
98.0280303107
113.027740058
128.027449863
143.027157991
158.026871578
Traceback (most recent call last):
File "<stdin>", line 2, in <module>

The other gets more complex
.... print t
.... time.sleep(5)
........ last = time.clock()
.... dumpTime(last)
.... time.sleep((last + 10.0) - time.clock())
....
199.787792062
209.791497063
219.791306975
229.79110609
239.790991578
249.790718419
Traceback (most recent call last):
File "<stdin>", line 3, in <module>

But if the function itself runs for longer than 10 seconds, there
will be a major problem, as the sleep apparently takes the argument as
unsigned, and a negative number is a very big sleep!
.... print t
.... time.sleep(11)
........ last = time.clock()
.... dumpTime(last)
.... time.sleep((last + 10.0) - time.clock())
....
403.96232976
Traceback (most recent call last):

Better limit the sleep
.... print t
.... time.sleep(11)
........ last = time.clock()
.... dumpTime(last)
.... time.sleep(max(0.0, (last + 10.0) - time.clock()))
....
608.521519761
619.517915274
630.517711063
641.5175254
652.517293743
663.517072219
674.516939156
685.516625507
696.516427311
707.516240174
718.515978656
729.51577823
740.515593446
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
File "<stdin>", line 3, in dumpTime
KeyboardInterrupt

 

[Laurent Claessens]

But if the function itself runs for longer than 10 seconds, there
will be a major problem, as the sleep apparently takes the argument as
unsigned, and a negative number is a very big sleep!

Launch each call in a separate thread. If the calls are independent,
this could be a solution.

Laurent

 

[Ulrich Eckhardt]

But if the function itself runs for longer than 10 seconds, there
will be a major problem, as the sleep apparently takes the argument as
unsigned, and a negative number is a very big sleep!

"time.sleep()" takes a floating point number, so an underflow like for
fixed-size integers in C shouldn't happen. What puzzles me here is your use
of "apparently", because here a negative value actually raises an "IOError:
[Errno 22] Invalid argument" when I call "sleep(-1)".

The system I'm on is a Debian GNU/Linux system running on some x86 hardware,
for the record, and I'm using Python 2.6.6.

Uli

 

[Dennis Lee Bieber]

"time.sleep()" takes a floating point number, so an underflow like for
fixed-size integers in C shouldn't happen. What puzzles me here is your use
of "apparently", because here a negative value actually raises an "IOError:
[Errno 22] Invalid argument" when I call "sleep(-1)".

The system I'm on is a Debian GNU/Linux system running on some x86 hardware,
for the record, and I'm using Python 2.6.6.

WinXP, Python 2.5.<something>

And that was a direct cut&paste from a command window; showing it
had slept for some 90 seconds before I killed it.

 

[MRAB]

"time.sleep()" takes a floating point number, so an underflow like for
fixed-size integers in C shouldn't happen. What puzzles me here is your use
of "apparently", because here a negative value actually raises an "IOError:
[Errno 22] Invalid argument" when I call "sleep(-1)".

The system I'm on is a Debian GNU/Linux system running on some x86 hardware,
for the record, and I'm using Python 2.6.6.

WinXP, Python 2.5.<something>

And that was a direct cut&paste from a command window; showing it
had slept for some 90 seconds before I killed it.

Looks like it hasn't changed even in WinXP, Python 3.2.

Is IOError what you'd expect, anyway?

What should it do in Python 3.2? Exception or max(seconds, 0)?

 

[Chris Angelico]

Looks like it hasn't changed even in WinXP, Python 3.2.

Is IOError what you'd expect, anyway?

What should it do in Python 3.2? Exception or max(seconds, 0)?

The obvious thing for it to do is to go back in time and resume
executing that many seconds ago, but failing that, I would have it do
the latter. It's already documented as potentially sleeping a bit
longer than the specified time (for instance, it's rounded up to the
minimum resolution, and task switches can increase the time), so it's
not much of a stretch to have negative sleep times result in a
yield/context switch and no further sleeping.

ChrisA

 

[Ian Kelly]

Looks like it hasn't changed even in WinXP, Python 3.2.

It gets cast to an unsigned long, so I expect sleep(-1) on Windows
would sleep for 2 ** 32 - 1000 ms, or about 49.7 days.

More interestingly, sleep(-0.001) should pass 2**32 - 1 to the
underlying Windows API, which would cause it to sleep forever (or
until interrupted).

Is IOError what you'd expect, anyway?

What should it do in Python 3.2? Exception or max(seconds, 0)?

sleep(0) has some special semantics on Windows. Raising ValueError
(or IOError to match Linux) makes the most sense to me.

Cheers,
Ian

 

[Ulrich Eckhardt]

And that was a direct cut&paste from a command window; showing it
had slept for some 90 seconds before I killed it.

Interesting. Just tried a 2.7.2 on a 32-bit MS Windows with following
results:

1. sleep(5 - 2**32) sleeps for a few seconds
2. sleep(-1) sleeps much longer

So this seems to confirm that it's a 32-bit underflow while preparing the
argument for win32's Sleep() function.

That said, an "IOError" is a bit better but still leaves room for
improvement. I'll take this to the developers mailinglist and see if they
consider the behaviour a bug. At the very least the docs are bad, I would
say.


Cheers!

Uli

 

[Dennis Lee Bieber]

So this seems to confirm that it's a 32-bit underflow while preparing the
argument for win32's Sleep() function.

That said, an "IOError" is a bit better but still leaves room for
improvement. I'll take this to the developers mailinglist and see if they
consider the behaviour a bug. At the very least the docs are bad, I would
say.

"RuntimeError" or "OSError" would seem to be better than "IOError";
though having the Python runtime incorporate a max(delay, 0) behind the
scenes would prevent both OS type behaviors.

 

[Ulrich Eckhardt]

I'll take this to the developers mailinglist and see if they
consider the behaviour a bug.

Filed as bug #12459.

Uli

 

[Dennis Lee Bieber]

from threading import Timer

def Func_to_call:
do_stuff()

my_timer = Timer(10, Func_to_call)
my_timer.start()

Timer() is a one-shot; per the OPs requirements even it would need
to be placed within a loop to invoke multiple calls -- so there isn't
much gain in terms of lines of code... And worse, since it calls the
function asynchronously and not sequentially, a delay time for each
instance would have to be computed inside the loop too...