On Thu, 3 Feb 2022 at 09:33, Barry <barry@barrys-emacs.org> wrote:
>
>
>
> > On 2 Feb 2022, at 21:12, Marco Sulla <Marco.Sulla.Python@gmail.com> wrote:
> >
> > You could add a __del__ that calls stop :)
>
> Didn’t python3 make this non deterministic when del is called?
>
> I thought the recommendation is to not rely on __del__ in python3 code.
>

The __del__ method is called when the object is being disposed of.
Aside from some considerations about interpreter shutdown, it's
perfectly reliable... as long as you understand that objects don't get
disposed of when they "go out of scope", but when they run out of
references and get garbage collected. So for instance, you can't
depend on "x = Spam(); x = Ham()" to dispose of the Spam object
instantly, because it might not get garbage collected instantly; but
you can depend on __del__ getting called when the Spam object gets
garbage collected.

With that said, I can guarantee you that a __del__ method is NOT the
right way to call stop, for one simple reason: the object will keep
its own references (via the timer) so long as it is running. So it
won't get garbage collected, and in fact, this is very important to it
being reliable. Consider this simpler example:

def call_soon(func):
t = threading.Timer(10, func)
t.start()

When this function returns, you can no longer refer to the object 't'.
Will the function be called at the appropriate time? Yes, it
absolutely will, and it would be highly surprising if it didn't! So
the thread itself keeps a reference to the important objects.

(Side point: The OP's code is quite inefficient, as it creates a new
thread for each reiteration, but there's nothing wrong with that if
you're looking for something simple.)

The main reason to "not rely on __del__" (and, by the way, that's
nothing to do with whether it's Python 2 or Python 3, this has been
true since early Py2 and possibly earlier) is that you don't know when
the object will be disposed of. So if you want to guarantee that
something is cleaned up, what you need is a way for the object itself
to still exist, but the corresponding resource to be cleaned up. A
classic example is a file object:

def read_then_write(fn):
with open(fn) as read_file:
data = read_file.read()
print(read_file)
# ... transform the data as required ...
with open(fn, "w") as write_file:
write_file.write(data)
print(write_file)

After each 'with' block, the file object is still there. You can refer
to it. Nothing has destroyed the object. But the file has been closed,
guaranteeing that you can safely reopen it in a different mode
(regardless of your OS). The same could be done with this timer; an
__exit__ method would make a lot of sense here, and would allow the
timer to be used in a with block to govern its execution. (It also
isn't really necessary, but if you want a good Pythonic way to show
the beginning and end of its use area, a 'with' block is the way to
go.)

ChrisA

Chris Angelico <rosuav@gmail.com> writes:

> On Thu, 3 Feb 2022 at 09:33, Barry <barry@barrys-emacs.org> wrote:
> (Side point: The OP's code is quite inefficient, as it creates a new
> thread for each reiteration, but there's nothing wrong with that if
> you're looking for something simple.)

It is just something I wrote fast. How could I do this in a better way?

> (regardless of your OS). The same could be done with this timer; an
> __exit__ method would make a lot of sense here, and would allow the
> timer to be used in a with block to govern its execution. (It also
> isn't really necessary, but if you want a good Pythonic way to show
> the beginning and end of its use area, a 'with' block is the way to
> go.)

I will look into that.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Cecil Westerhof <Cecil@decebal.nl> writes:

>> (regardless of your OS). The same could be done with this timer; an
>> __exit__ method would make a lot of sense here, and would allow the
>> timer to be used in a with block to govern its execution. (It also
>> isn't really necessary, but if you want a good Pythonic way to show
>> the beginning and end of its use area, a 'with' block is the way to
>> go.)
>
> I will look into that.

Implemented:
from threading import Timer

class repeated_timer(object):
def __init__(self, fn, interval, start = False):
if not callable(fn):
raise TypeError('{} is not a function'.format(fn))
self._fn = fn
self._check_interval(interval)
self._interval = interval
self._timer = None
self._is_running = False
if start:
self.start()

def __enter__(self):
return self

def __exit__(self, exc_type, exc_val, exc_tb):
self.stop()

def _check_interval(self, interval):
if not type(interval) in [int, float]:
raise TypeError('{} is not numeric'.format(interval))
if interval <= 0:
raise ValueError('{} is not greater as 0'.format(interval))

def _next(self):
self._timer = Timer(self._interval, self._run)
self._timer.start()

def _run(self):
self._next()
self._fn()

def set_interval(self, interval):
self._check_interval(interval)
self._interval = interval

def start(self):
if not self._is_running:
self._is_running = True
self._next()

def stop(self):
if self._is_running:
self._timer.cancel()
self._timer = None
self._is_running = False

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

You have:

def _check_interval(self, interval):
if not type(interval) in [int, float]:
raise TypeError('{} is not numeric'.format(interval))

This check is better written:

if not isinstance(interval, (int,float)):

which handles subclasses of these types (but note that bool subclasses
int :-) normally we don't care), or behaviourally:

try:
interval = float(interval)
except ValueError as e:
raise TypeError(
"cannot convert %s:%r to float: %s"
% (type(interval).__name__, interval, e)) from e

which tries to convert to float and fails if that does not work, which
supports classes with a __float__ method (these classes are rare, but
decimal.Decimal is one example).

I'd probably use the isinstance() form myself.

Cheers,
Cameron Simpson <cs@cskk.id.au>

On Thu, 3 Feb 2022 at 12:24, Cecil Westerhof via Python-list
<python-list@python.org> wrote:
>
> Chris Angelico <rosuav@gmail.com> writes:
>
> > On Thu, 3 Feb 2022 at 09:33, Barry <barry@barrys-emacs.org> wrote:
> > (Side point: The OP's code is quite inefficient, as it creates a new
> > thread for each reiteration, but there's nothing wrong with that if
> > you're looking for something simple.)
>
> It is just something I wrote fast. How could I do this in a better way?

I'll answer your question, but first and foremost: Your code was fine,
and if something does what it's supposed to, that is the most
important. Everything else is minor.

But for other ways to do things, I would recommend creating a single
thread function and spawning a single thread to run it, and then
having that function call the target every N seconds. Also, consider
subclassing Thread rather than subclassing object (which, btw, is the
default; you don't need to say "class X(object)"), which will
automatically give your object all the methods of a timer.

If you feel like it, you could even look into ways to do things
without threads, but that would be a much bigger change :)

But remember: when your code does what it's supposed to, it is *fine*,
and doesn't need changing. I'm not saying that your code is bad :)

ChrisA

Cameron Simpson <cs@cskk.id.au> writes:

> You have:
>
> def _check_interval(self, interval):
> if not type(interval) in [int, float]:
> raise TypeError('{} is not numeric'.format(interval))
>
> This check is better written:
>
> if not isinstance(interval, (int,float)):
>
> which handles subclasses of these types (but note that bool subclasses
> int :-)

Done, thanks.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

On 2022-02-03 at 12:39:43 +1100,
Cameron Simpson <cs@cskk.id.au> wrote:

> You have:
>
> def _check_interval(self, interval):
> if not type(interval) in [int, float]:
> raise TypeError('{} is not numeric'.format(interval))
>
> This check is better written:
>
> if not isinstance(interval, (int,float)):
>
> which handles subclasses of these types (but note that bool subclasses
> int :-) normally we don't care), or behaviourally:
>
> try:
> interval = float(interval)
> except ValueError as e:
> raise TypeError(
> "cannot convert %s:%r to float: %s"
> % (type(interval).__name__, interval, e)) from e
>
> which tries to convert to float and fails if that does not work, which
> supports classes with a __float__ method (these classes are rare, but
> decimal.Decimal is one example).

I think this can be simplified for time intervals to the following:

if interval <= 0:
raise ValueError(...)

which accepts non-negative real values; throws ValueError for negative
real values; and TypeError for other stuff, including complex numbers
(pathological types notwithstanding). One thing that doesn't work right
is NaNs, but I'm sure it's not the only code that acts weirdly when
faced with a NaM (curiously, Timer accepts a NaN, but the text I get
from help(Timer) in Python 3.10.2 is, well, broken).

FWIW, I'd find some way to tell users the units (seconds, milliseconds,
fortnights, etc.) instead of making them wade through your code to find
the call to (and possibly the [broken] help text of) Timer.

Chris Angelico <rosuav@gmail.com> writes:

>> > (Side point: The OP's code is quite inefficient, as it creates a new
>> > thread for each reiteration, but there's nothing wrong with that if
>> > you're looking for something simple.)
>>
>> It is just something I wrote fast. How could I do this in a better way?
>
> I'll answer your question, but first and foremost: Your code was fine,
> and if something does what it's supposed to, that is the most
> important. Everything else is minor.

I like to write efficient code and it never hurts to write better code
as just doing what it is supposed to do. ;-)

And in my case interval is .5 seconds and when someone is going to use
it with an even smaller interval …

> But for other ways to do things, I would recommend creating a single
> thread function and spawning a single thread to run it, and then
> having that function call the target every N seconds. Also, consider

Have to be careful that timing keeps correct when target takes a 'lot'
of time.
Something to ponder about, but can wait.

> subclassing Thread rather than subclassing object (which, btw, is the
> default; you don't need to say "class X(object)"), which will
> automatically give your object all the methods of a timer.

Of-course. I should have thought about that. :'-(

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

On Thu, 3 Feb 2022 at 14:52, <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
>
> On 2022-02-03 at 12:39:43 +1100,
> Cameron Simpson <cs@cskk.id.au> wrote:
>
> > You have:
> >
> > def _check_interval(self, interval):
> > if not type(interval) in [int, float]:
> > raise TypeError('{} is not numeric'.format(interval))
> >
> > This check is better written:
> >
> > if not isinstance(interval, (int,float)):
> >
> > which handles subclasses of these types (but note that bool subclasses
> > int :-) normally we don't care), or behaviourally:
> >
> > try:
> > interval = float(interval)
> > except ValueError as e:
> > raise TypeError(
> > "cannot convert %s:%r to float: %s"
> > % (type(interval).__name__, interval, e)) from e
> >
> > which tries to convert to float and fails if that does not work, which
> > supports classes with a __float__ method (these classes are rare, but
> > decimal.Decimal is one example).
>
> I think this can be simplified for time intervals to the following:
>
> if interval <= 0:
> raise ValueError(...)

That's checking something quite different, though. Casting to float
will accept anything that can be, well, cast to float, but checking
for less than or equal to zero demands that it already be some sort of
number. It's debatable which check is more correct, but certainly this
is not a simplification of the other code, it's a distinctly different
validation.

> which accepts non-negative real values; throws ValueError for negative
> real values; and TypeError for other stuff, including complex numbers
> (pathological types notwithstanding). One thing that doesn't work right
> is NaNs, but I'm sure it's not the only code that acts weirdly when
> faced with a NaM (curiously, Timer accepts a NaN, but the text I get
> from help(Timer) in Python 3.10.2 is, well, broken).

Strange. The text I get in 3.11.0a1 is fine. But in any case, there's
always the docs on the web.

https://docs.python.org/3/library/threading.html#timer-objects

> FWIW, I'd find some way to tell users the units (seconds, milliseconds,
> fortnights, etc.) instead of making them wade through your code to find
> the call to (and possibly the [broken] help text of) Timer.

In anything in Python, assume that the unit is seconds. With anything
that accepts floats (where these can be distinguished from integers),
assume the unit is seconds. If it accepts micro or nanoseconds, it'll
almost certainly be called "high resolution timer" (unless it accepts
two args, sec and us/ns, but that's pretty obvious), so you can
generally exclude those too. The only real question is whether
sleep(int) takes seconds or milliseconds, which isn't a problem here.

Citation: I've slept in many many programming languages and
frameworks. Which sounds seriously weird, but you're all programmers,
you know what I mean :)

ChrisA

On 2022-02-03 at 15:07:22 +1100,
Chris Angelico <rosuav@gmail.com> wrote:

> On Thu, 3 Feb 2022 at 14:52, <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
> >
> > On 2022-02-03 at 12:39:43 +1100,
> > Cameron Simpson <cs@cskk.id.au> wrote:
> >
> > > You have:
> > >
> > > def _check_interval(self, interval):
> > > if not type(interval) in [int, float]:
> > > raise TypeError('{} is not numeric'.format(interval))
> > >
> > > This check is better written:
> > >
> > > if not isinstance(interval, (int,float)):
> > >
> > > which handles subclasses of these types (but note that bool subclasses
> > > int :-) normally we don't care), or behaviourally:
> > >
> > > try:
> > > interval = float(interval)
> > > except ValueError as e:
> > > raise TypeError(
> > > "cannot convert %s:%r to float: %s"
> > > % (type(interval).__name__, interval, e)) from e
> > >
> > > which tries to convert to float and fails if that does not work, which
> > > supports classes with a __float__ method (these classes are rare, but
> > > decimal.Decimal is one example).
> >
> > I think this can be simplified for time intervals to the following:
> >
> > if interval <= 0:
> > raise ValueError(...)
>
> That's checking something quite different, though. Casting to float
> will accept anything that can be, well, cast to float, but checking
> for less than or equal to zero demands that it already be some sort of
> number. It's debatable which check is more correct, but certainly this
> is not a simplification of the other code, it's a distinctly different
> validation.

Okay, "simplified" isn't quite the right word. Given two examples (with
known deficiencies) and no actual use cases or specifications, I added a
third example, which I believed was simpler (and arguably better in one
or more ways, which I explained), than the others.

> > which accepts non-negative real values; throws ValueError for negative
> > real values; and TypeError for other stuff, including complex numbers
> > (pathological types notwithstanding). One thing that doesn't work right
> > is NaNs, but I'm sure it's not the only code that acts weirdly when
> > faced with a NaM (curiously, Timer accepts a NaN, but the text I get
> > from help(Timer) in Python 3.10.2 is, well, broken).
>
> Strange. The text I get in 3.11.0a1 is fine. But in any case, there's
> always the docs on the web.
>
> https://docs.python.org/3/library/threading.html#timer-objects

help(Timer) is built into my REPL (and likely consumed by development
systems and IDEs everywhere). No web necessary.

> > FWIW, I'd find some way to tell users the units (seconds, milliseconds,
> > fortnights, etc.) instead of making them wade through your code to find
> > the call to (and possibly the [broken] help text of) Timer.
>
> In anything in Python, assume that the unit is seconds. With anything
> that accepts floats (where these can be distinguished from integers),
> assume the unit is seconds. If it accepts micro or nanoseconds, it'll
> almost certainly be called "high resolution timer" (unless it accepts
> two args, sec and us/ns, but that's pretty obvious), so you can
> generally exclude those too. The only real question is whether
> sleep(int) takes seconds or milliseconds, which isn't a problem here.
>
> Citation: I've slept in many many programming languages and
> frameworks. Which sounds seriously weird, but you're all programmers,
> you know what I mean :)

I've slept in enough programming environments to know better than to
assume anything. ;-)

On Thu, 3 Feb 2022 at 15:28, <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
>
> On 2022-02-03 at 15:07:22 +1100,
> Chris Angelico <rosuav@gmail.com> wrote:
>
> > On Thu, 3 Feb 2022 at 14:52, <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
> > >
> > > On 2022-02-03 at 12:39:43 +1100,
> > > Cameron Simpson <cs@cskk.id.au> wrote:
> > >
> > > > You have:
> > > >
> > > > def _check_interval(self, interval):
> > > > if not type(interval) in [int, float]:
> > > > raise TypeError('{} is not numeric'.format(interval))
> > > >
> > > > This check is better written:
> > > >
> > > > if not isinstance(interval, (int,float)):
> > > >
> > > > which handles subclasses of these types (but note that bool subclasses
> > > > int :-) normally we don't care), or behaviourally:
> > > >
> > > > try:
> > > > interval = float(interval)
> > > > except ValueError as e:
> > > > raise TypeError(
> > > > "cannot convert %s:%r to float: %s"
> > > > % (type(interval).__name__, interval, e)) from e
> > > >
> > > > which tries to convert to float and fails if that does not work, which
> > > > supports classes with a __float__ method (these classes are rare, but
> > > > decimal.Decimal is one example).
> > >
> > > I think this can be simplified for time intervals to the following:
> > >
> > > if interval <= 0:
> > > raise ValueError(...)
> >
> > That's checking something quite different, though. Casting to float
> > will accept anything that can be, well, cast to float, but checking
> > for less than or equal to zero demands that it already be some sort of
> > number. It's debatable which check is more correct, but certainly this
> > is not a simplification of the other code, it's a distinctly different
> > validation.
>
> Okay, "simplified" isn't quite the right word. Given two examples (with
> known deficiencies) and no actual use cases or specifications, I added a
> third example, which I believed was simpler (and arguably better in one
> or more ways, which I explained), than the others.

Fair :) I'm unsure which is the best check here, or whether it's worth
having any check at all (you could just let the Timer - or
time.sleep() - do the checks).

> > Strange. The text I get in 3.11.0a1 is fine. But in any case, there's
> > always the docs on the web.
> >
> > https://docs.python.org/3/library/threading.html#timer-objects
>
> help(Timer) is built into my REPL (and likely consumed by development
> systems and IDEs everywhere). No web necessary.

Agreed, and my primary response is that it's fine in my 3.11, so it's
probably something fixable. The web docs are a good fallback though.

> I've slept in enough programming environments to know better than to
> assume anything. ;-)

Excellent :)

ChrisA

On Thu, 3 Feb 2022 at 15:43, Cecil Westerhof via Python-list
<python-list@python.org> wrote:
>
> Chris Angelico <rosuav@gmail.com> writes:
>
> >> > (Side point: The OP's code is quite inefficient, as it creates a new
> >> > thread for each reiteration, but there's nothing wrong with that if
> >> > you're looking for something simple.)
> >>
> >> It is just something I wrote fast. How could I do this in a better way?
> >
> > I'll answer your question, but first and foremost: Your code was fine,
> > and if something does what it's supposed to, that is the most
> > important. Everything else is minor.
>
> I like to write efficient code and it never hurts to write better code
> as just doing what it is supposed to do. ;-)
>
> And in my case interval is .5 seconds and when someone is going to use
> it with an even smaller interval …
>
>
> > But for other ways to do things, I would recommend creating a single
> > thread function and spawning a single thread to run it, and then
> > having that function call the target every N seconds. Also, consider
>
> Have to be careful that timing keeps correct when target takes a 'lot'
> of time.
> Something to ponder about, but can wait.

Ah. In that case, I would recommend a different look at things.
Instead of waiting X time, then firing the event, then waiting X time,
consider instead an interval timer based on monotonic time:

https://docs.python.org/3/library/time.html#time.monotonic

When the timer starts, record the current monotonic time, and sleep
one interval. After the function returns, sleep the remainder of one
interval. It's up to you what happens if you ever find that the next
time point has already passed - do you call the function immediately,
or skip and wait for the next moment?

Interval timers have some complexity to them, but it's worth putting
in the time (pun intended) to figure out how these things work :)

ChrisA

2QdxY4RzWzUUiLuE@potatochowder.com writes:

> FWIW, I'd find some way to tell users the units (seconds, milliseconds,
> fortnights, etc.) instead of making them wade through your code to find
> the call to (and possibly the [broken] help text of) Timer.

You mean with docstring?

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Chris Angelico <rosuav@gmail.com> writes:

> On Thu, 3 Feb 2022 at 15:43, Cecil Westerhof via Python-list
> <python-list@python.org> wrote:
>>
>> Chris Angelico <rosuav@gmail.com> writes:
>>
>> >> > (Side point: The OP's code is quite inefficient, as it creates a new
>> >> > thread for each reiteration, but there's nothing wrong with that if
>> >> > you're looking for something simple.)
>> >>
>> >> It is just something I wrote fast. How could I do this in a better way?
>> >
>> > I'll answer your question, but first and foremost: Your code was fine,
>> > and if something does what it's supposed to, that is the most
>> > important. Everything else is minor.
>>
>> I like to write efficient code and it never hurts to write better code
>> as just doing what it is supposed to do. ;-)
>>
>> And in my case interval is .5 seconds and when someone is going to use
>> it with an even smaller interval …
>>
>>
>> > But for other ways to do things, I would recommend creating a single
>> > thread function and spawning a single thread to run it, and then
>> > having that function call the target every N seconds. Also, consider
>>
>> Have to be careful that timing keeps correct when target takes a 'lot'
>> of time.
>> Something to ponder about, but can wait.
>
> Ah. In that case, I would recommend a different look at things.
> Instead of waiting X time, then firing the event, then waiting X time,
> consider instead an interval timer based on monotonic time:
>
> https://docs.python.org/3/library/time.html#time.monotonic
>
> When the timer starts, record the current monotonic time, and sleep
> one interval. After the function returns, sleep the remainder of one
> interval. It's up to you what happens if you ever find that the next
> time point has already passed - do you call the function immediately,
> or skip and wait for the next moment?
>
> Interval timers have some complexity to them, but it's worth putting
> in the time (pun intended) to figure out how these things work :)

I will look into it.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

On 2022-02-03 at 05:52:19 +0100,
Cecil Westerhof via Python-list <python-list@python.org> wrote:

> 2QdxY4RzWzUUiLuE@potatochowder.com writes:
>
> > FWIW, I'd find some way to tell users the units (seconds, milliseconds,
> > fortnights, etc.) instead of making them wade through your code to find
> > the call to (and possibly the [broken] help text of) Timer.
>
> You mean with docstring?

Docstring, comments, error/exception text, external documentation, URLs
or other references in the source code (docstring, comments), the name
of the object in question (e.g., instead of "interval," call it
"interval_seconds," or "seconds_between_runs"). *Something*. Or more
than one of the above. A reference to the Timer class's documentation.
There are a lot of options.

Pick a place (or more than one!) that will be fairly conspicuous in as
many situations to as many users (including future you) or potential
users (including your future code) as possible.

In a perfect world, you will receive feedback and/or use your own code,
and improve your choice(s) and method(s) over time.

> On 3 Feb 2022, at 04:45, Cecil Westerhof via Python-list <python-list@python.org> wrote:
>
> Have to be careful that timing keeps correct when target takes a 'lot'
> of time.
> Something to ponder about, but can wait.

You have noticed that your class does call the function at the repeat interval but
rather at the repeat interval plus processing time.

The way to fix this is to subtract the last processing elapsed time for the next interval.
Sort of a software phase locked loop.

Just before you call the run function record the time.time() as start_time.
Then you can calculate next_interval = max( .001, interval - time.time() - start_time)
I use 1ms as the min interval.

Barry

Barry <barry@barrys-emacs.org> writes:

>> On 3 Feb 2022, at 04:45, Cecil Westerhof via Python-list <python-list@python.org> wrote:
>>
>> Have to be careful that timing keeps correct when target takes a 'lot'
>> of time.
>> Something to ponder about, but can wait.
>
> You have noticed that your class does call the function at the repeat interval but
> rather at the repeat interval plus processing time.

Nope:
def _next(self):
self._timer = Timer(self._interval, self._run)
self._timer.start()

def _run(self):
self._next()
self._fn()

In _run I first set the new timer and then I execute the function. So
that will go mostly OK.

> The way to fix this is to subtract the last processing elapsed time for the next interval.
> Sort of a software phase locked loop.
>
> Just before you call the run function record the time.time() as start_time.
> Then you can calculate next_interval = max( .001, interval - time.time() - start_time)
> I use 1ms as the min interval.

But I am working on a complete rewrite to create a more efficient
class. (This means I have to change also the code that uses it.) There
I have to do something like you suggest. (I am already working on it.)

Personally I am also of the opinion that the function should finish in
less as 10% from the interval. (That was one of my rewrites.)

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

>In _run I first set the new timer and then I execute the function. So
>that will go mostly OK.

Yes, that's correct however you are not taking into consideration the
imprecision of the timers.

Timer will call the next _run() after self._interval *plus* some unknown
arbitrary time (and extra delay).

Let's assume that when you setup an 1 sec Timer but the Timer calls
_run() after 1.01 secs due this unknown extra delay.

The first time fn() should be called after 1 sec since the begin but it
is called after 1.01 secs so the extra delay was of 0.01 sec.

The second time fn() should be called after 2 secs since the begin but
it is called after 2.02 secs. The second fn() was delayed not by 0.01
but by 0.02 secs.

The third fn() will be delayed by 0.03 secs and so on.

This arbitrary delay is very small however it will sum up on each
iteration and depending of your application can be a serious problem.

I wrote a post about this and how to create "constant rate loops" which
fixes this problem:
https://book-of-gehn.github.io/articles/2019/10/23/Constant-Rate-Loop.html

In the post I also describe two solutions (with their trade-offs) for
when the target function fn() takes longer than the self._interval time.

See if it helps.

Thanks,
Martin.

On Thu, Feb 03, 2022 at 11:41:42PM +0100, Cecil Westerhof via
Python-list wrote:
>Barry <barry@barrys-emacs.org> writes:
>
>>> On 3 Feb 2022, at 04:45, Cecil Westerhof via Python-list <python-list@python.org> wrote:
>>>
>>> Have to be careful that timing keeps correct when target takes a 'lot'
>>> of time.
>>> Something to ponder about, but can wait.
>>
>> You have noticed that your class does call the function at the repeat interval but
>> rather at the repeat interval plus processing time.
>
>Nope:
> def _next(self):
> self._timer = Timer(self._interval, self._run)
> self._timer.start()
>
> def _run(self):
> self._next()
> self._fn()
>
>In _run I first set the new timer and then I execute the function. So
>that will go mostly OK.
>
>
>> The way to fix this is to subtract the last processing elapsed time for the next interval.
>> Sort of a software phase locked loop.
>>
>> Just before you call the run function record the time.time() as start_time.
>> Then you can calculate next_interval = max( .001, interval - time.time() - start_time)
>> I use 1ms as the min interval.
>
>But I am working on a complete rewrite to create a more efficient
>class. (This means I have to change also the code that uses it.) There
>I have to do something like you suggest. (I am already working on it.)
>
>
>Personally I am also of the opinion that the function should finish in
>less as 10% from the interval. (That was one of my rewrites.)
>
>--
>Cecil Westerhof
>Senior Software Engineer
>LinkedIn: http://www.linkedin.com/in/cecilwesterhof
>--
>https://mail.python.org/mailman/listinfo/python-list