Comparisons using just the time object without an attached date
are pretty buggy and incomplete -- comparisons only make sense when
given a particular instant of time.
Ref: #7676
Relative time intervals can be thought of as:
for _ in range(count):
await body()
await asyncio.sleep(interval)
While explicit time intervals should be thought of as:
times = [1pm, 2pm, 3pm, 12am]
current = 0
for _ in range(count):
time = times.wrapping_index(current) # magic to wrap around
await utils.sleep_until(time)
await body()
current += 1
In a scenario with `tasks.loop(seconds=5)`:
The task takes 30 seconds to run on the first two iterations, and then
is nearly instant for iterations afterward. The behavior should be
that the task runs at:
t = 0 (on time)
t = 30 (late, should've been at t = 5)
t = 60 (late, should've been at t = 10)
t = 60 (late, should've been at t = 15)
t = 60 (late, should've been at t = 20)
t = 60 (late, should've been at t = 25)
... 6 more iterations
t = 60 (on time)
t = 65 (on time)
In a scenario with a loop with explicit times set at UTC 1pm, 2pm,
3pm, 4pm, and 5pm:
- The task takes 6 hour to run on the first iteration, and then is
nearly instant for iterations afterward. Assuming the task is started
at noon, the behavior should be that the task runs at `t = 0` and
then at `t = 3600` 4 times ("catching up" on the missed iterations
at 2pm, 3pm, 4pm, and 5pm).
- The task takes 30 days to run on the first iteration, and then is
nearly instant for iterations afterward. Assuming the task is started
at noon, the behavior should be that the task runs at `t = 0` and
then at `t = 43200` 149 times ("catching up" on the missed
iterations for the past month).
This behavior should be documented in the ext.tasks docs
Segments where readability was hampered were fixed by appropriate
format skipping directives. New code should hopefully be black
compatible. The moment they remove the -S option is probably the moment
I stop using black though.
This change makes it more so that `Loop.stop()` gracefully makes the
current iteration the final one, by waiting AND THEN returning.
The current implementation is closer to `cancel`, while also not.
I encountered this because I was trying to run a
`@tasks.loop(count=1)`, and inside it I print some text and change the
interval, and in an `after_loop`, I restart the loop.
Without this change, it immediately floods my console, due to
not waiting before executing `after_loop`.
self._task is only None if the Loop has never been started before,
which means None should be returned always, regardless of how
many seconds was passed into the constructor
this didn't break anything before because self._next_iteration will
be None as well if self._task is None.
Task cancel raises on the next awaited coro, so I've added this 0-sleep "hack"
I'm internally debating if leaving the comment there, but I'm sure it would confuse the uninformed of this trick.
At this moment, when a task seems to be first loaded, it immediately throws away the decorators you give it, and just generates a new instance of itself.
In your cog's `__init__`, once you do `self.my_task.start()`, the Loop is remade when it gets to `self.my_task` before executing the `start` function. The original Loop that the cog starts with is where the decorated values are. This fixes that.
IoniteandGitHub
Bryan ForbesandGitHub
Rapptz
Lilly Rose BernerandGitHub
Han Seung Min - 한승민andGitHub
Sebastian LawandGitHub
ChrovoandGitHub
Nadir ChowdhuryandGitHub
NiumXpandGitHub
Steve CandGitHub
Sebastian LawandGitHub
Nihaal SanghaandGitHub
Dan HessandGitHub
JamesandRapptz
EpicandRapptz
JamesandRapptz