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
This results in poor ergonomics due to the lack of default generics
for the common case. For most users this ends up in a degraded
experience since the type will resolve to Unknown rather than at the
very least a Client.
This has potential to be a breaking change and Discord could definitely
royally screw this over in the future. However, as far as I can tell
every interaction has either a User or a Member so this change should
be kosher. I'm unaware of any interaction, even in the future, where
this is not true.
I hope these are not my famous last words.
This implements it in three different ways:
* The first is using typing.Literal for quick and easy ones
* The second is using enum.Enum for slightly more complex ones
* The last is using a Choice type hint with a decorator to pass
a list of choices.
This should hopefully cover most use cases.
This facilitates the "converter-like" API of the app_commands
submodule. As a consequence of this refactor, more types are supported
like channels and attachment.
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
