An optional tick_at_start parameter has been added to Timer
#372
Conversation
Signed-off-by: Sahas Subramanian <[email protected]>
Signed-off-by: Sahas Subramanian <[email protected]>
Signed-off-by: Sahas Subramanian <[email protected]>
github-actions
bot
added
part:docs
|
FYI @cwasicki |
| triggering for the first time. If `auto_start` is `False` and | ||
| this is `True`, an exception is raised. If a `start_delay` is | ||
| specified and this is `True`, the first trigger will be immediately | ||
| after the `start_delay`. |
There was a problem hiding this comment.
One use-case we have is that you want to trigger immediately, then wait for start_delay and from that point onward trigger each interval. This is not possible still with this addition, correct?
There was a problem hiding this comment.
I wonder whether it should be tick_on_init and the combination of tick_at_init=True and start_delay=X should function like that?
There was a problem hiding this comment.
This is not possible still with this addition, correct?
No, I remember that use case and this should reduce its complexity and make it readable.
But I feel that this is the right balance, and tick_on_init + tick_on_start would make the API for the Timer too complex.
But we can come back to it. And if we are going to add more tick_on_* policies, maybe we should consider an enum instead, describing when to tick.
There was a problem hiding this comment.
What I meant is replace tick_on_start with tick_on_init because AFAIU the behavior here can be achieved with a tick_on_init but what I outlined above is not possible with a tick_on_start.
There was a problem hiding this comment.
If we have only tick_on_init, then someone who wants just tick_on_start will get too many ticks and would need more complicated workarounds than someone who needs tick_on_init but only has tick_on_start.
There was a problem hiding this comment.
Discussed in person, we take it in for now and keep potential changes for v2.0
There was a problem hiding this comment.
I've added an item describing the 2.0 plan here: #365
| triggering for the first time. If `auto_start` is `False` and | ||
| this is `True`, an exception is raised. If a `start_delay` is |
There was a problem hiding this comment.
I don't get why raising if auto_start is False? What is the issue with making this first tick delayed to when the timer actually starts, like when using start_delay?
There was a problem hiding this comment.
Restricted by how it is implemented. But if they need it, users can specify tick_on_start=True in the call to reset, just like with start_delay.
There was a problem hiding this comment.
What is the issue with making this first tick delayed to when the timer actually starts, like when using
start_delay?
No, that's not how start_delay is implemented. It also doesn't work with auto_start=False.
3 participants
When
True, the timer will trigger immediately after starting, and then wait for the interval before triggering again.