time_after_time
But to be more pythonic, throw some double underscores before and after.
-Original Message-
From: Igor Berger
To: python-list@python.org
Sent: Fri, Feb 4, 2022 12:40 pm
Subject: Re: Waht do you think about my repeated_timer class
On Friday, February 4, 2022 at 12:28:53
Chris Angelico writes:
> On Sat, 5 Feb 2022 at 04:33, Cecil Westerhof via Python-list
> wrote:
>>
>> Ethan Furman writes:
>>
>> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
>> >
>> >> It was already not a good name, but I am rewriting the class
>> >> completely, so now the name i
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
On Sat, 5 Feb 2022 at 04:33, Cecil Westerhof via Python-list
wrote:
>
> Ethan Furman writes:
>
> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
> >
> >> It was already not a good name, but I am rewriting the class
> >> completely, so now the name is a complete bumper. (No more timer.
Igor Berger writes:
> On Friday, February 4, 2022 at 12:28:53 PM UTC-5, Cecil Westerhof wrote:
>> Ethan Furman writes:
>>
>> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
>> >
>> >> It was already not a good name, but I am rewriting the class
>> >> completely, so now the name
On Friday, February 4, 2022 at 12:28:53 PM UTC-5, Cecil Westerhof wrote:
> Ethan Furman writes:
>
> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
> >
> >> It was already not a good name, but I am rewriting the class
> >> completely, so now the name is a complete bumper. (No more
Ethan Furman writes:
> On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
>
>> It was already not a good name, but I am rewriting the class
>> completely, so now the name is a complete bumper. (No more timer.) I
>> am thinking about naming the class repeating_thread, but I cannot say
>> th
On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
> It was already not a good name, but I am rewriting the class
> completely, so now the name is a complete bumper. (No more timer.) I
> am thinking about naming the class repeating_thread, but I cannot say
> that I find it a very good name
Cecil Westerhof writes:
It was already not a good name, but I am rewriting the class
completely, so now the name is a complete bumper. (No more timer.) I
am thinking about naming the class repeating_thread, but I cannot say
that I find it a very good name. So if someone has a good idea for a
name
Barry writes:
>> On 3 Feb 2022, at 04:45, Cecil Westerhof via Python-list
>> 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
>
> On 3 Feb 2022, at 04:45, Cecil Westerhof via Python-list
> 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 t
On Feb 2, 2022 23:31, Barry wrote:
> On 2 Feb 2022, at 21:12, Marco Sulla
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
On 2022-02-03 at 05:52:19 +0100,
Cecil Westerhof via Python-list wrote:
> 2qdxy4rzwzuui...@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 poss
Chris Angelico writes:
> On Thu, 3 Feb 2022 at 15:43, Cecil Westerhof via Python-list
> wrote:
>>
>> Chris Angelico 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
Cecil Westerhof writes:
> I need (sometimes) to repeatedly execute a function. For this I wrote
> the below class. What do you think about it?
I wrote some unit test for the class. Is this the correct way to do
this?
For example in test_correct_params_no_start I check four things. Some
people sa
2qdxy4rzwzuui...@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 Westerho
On Thu, 3 Feb 2022 at 15:43, Cecil Westerhof via Python-list
wrote:
>
> Chris Angelico 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.)
> >>
Chris Angelico 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'
On Thu, 3 Feb 2022 at 15:28, <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2022-02-03 at 15:07:22 +1100,
> Chris Angelico wrote:
>
> > On Thu, 3 Feb 2022 at 14:52, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> > >
> > > On 2022-02-03 at 12:39:43 +1100,
> > > Cameron Simpson wrote:
> > >
> >
On 2022-02-03 at 15:07:22 +1100,
Chris Angelico wrote:
> On Thu, 3 Feb 2022 at 14:52, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2022-02-03 at 12:39:43 +1100,
> > Cameron Simpson wrote:
> >
> > > You have:
> > >
> > > def _check_interval(self, interval):
> > > if not type
On Thu, 3 Feb 2022 at 14:52, <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2022-02-03 at 12:39:43 +1100,
> Cameron Simpson wrote:
>
> > You have:
> >
> > def _check_interval(self, interval):
> > if not type(interval) in [int, float]:
> > raise TypeError('{} is not nume
On 2022-02-03 at 12:39:43 +1100,
Cameron Simpson 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(inte
Cameron Simpson 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 handl
On Thu, 3 Feb 2022 at 12:24, Cecil Westerhof via Python-list
wrote:
>
> Chris Angelico writes:
>
> > On Thu, 3 Feb 2022 at 09:33, Barry 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'
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
Cecil Westerhof 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 wa
Chris Angelico writes:
> On Thu, 3 Feb 2022 at 09:33, Barry 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
On Thu, 3 Feb 2022 at 09:33, Barry wrote:
>
>
>
> > On 2 Feb 2022, at 21:12, Marco Sulla 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
> On 2 Feb 2022, at 21:12, Marco Sulla 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.
Barry
>
>> On Wed, 2 Feb 2022 at 21:23, Cecil Westerhof via Py
You could add a __del__ that calls stop :)
On Wed, 2 Feb 2022 at 21:23, Cecil Westerhof via Python-list
wrote:
>
> I need (sometimes) to repeatedly execute a function. For this I wrote
> the below class. What do you think about it?
> from threading import Timer
>
>
>
> class repeated_tim
I need (sometimes) to repeatedly execute a function. For this I wrote
the below class. What do you think about it?
from threading import Timer
class repeated_timer(object):
def __init__(self, fn, interval, start = False):
if not callable(fn):
raise Ty
31 matches
Mail list logo
