| Commit message (Collapse) | Author | Lines |
|
It'd fail to schedule the coroutine otherwise anyway. There is also the
potential to close the coroutine, which may be unexpected to see for a
coroutine that was already running (despite being documented).
|
|
Showing the task ID in the logs makes them distinguishable from logs for
other tasks.
The coroutine state is logged because it may come in handy while
debugging; the coroutine inspection check hasn't been proven yet in
production.
|
|
|
|
|
|
The coroutine may cancel the scheduled task, which would also trigger
the finally block. The coroutine isn't necessarily finished when it
cancels the task, so it shouldn't be closed in this case.
|
|
The task is already popped from the dict, so there is no need to delete
it afterwards.
|
|
This prevents unawaited coroutine warnings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Naming it "task" is inaccurate because `create_task` accepts a coroutine
rather than a Task. What it does is wrap the coroutine in a Task.
|
|
It's redundant. After all, this scheduler cannot schedule anything else.
|
|
The ability to use the `in` operator makes this obsolete. Callers can
check themselves if a task exists before they try to cancel it.
|
|
|
|
|
|
Makes them easier to identify when debugging.
|
|
This is a major change which simplifies the interface. It removes the
need to implement an abstract method, which means the class can now
be instantiated rather than subclassed.
|
|
Each instance now requires a name to be specified, which will be used
as the suffix of the logger's name. This removes the need to manually
prepend every log message with the name.
|