Open jakkdl opened 7 months ago
I don't think we should support other libraries - curio is no longer being updated, twisted is more callback than async, others are even smaller.
finally:
or except BaseException/trio.Cancelled
unless you use a shielded cancel scope with a timeout.
while <condition>: await trio.sleep()
should be replaced by a trio.Event
.
asyncio.Event
timeout
parameter - use trio.[fail/move_on]_[after/at]
instead
with trio.fail_after(...):
or with trio.move_on_after(...):
context does not contain any await
statements. This makes it pointless, as
the timeout can only be triggered by a checkpoint.
asyncio.timeout
, asyncio.timeout_at
, trio.sleep()
with >24 hour interval should usually be trio.sleep_forever()
.asyncio.sleep_forever()
as far as I can tell.asyncio.sleep(0)
instead of library.lowlevel.checkpoint()
. [No longer blocked by test infra]start[_soon]
might be invalidly accessed while in use, due to context manager closing before the nursery. This is usually a bug, and nurseries should generally be the inner-most context manager.nursery.start[_soon]
and not passing itself as a parameter can be replaced with a regular function call.yield
inside a nursery or cancel scope is only safe when implementing a context manager - otherwise, it breaks exception handling.start_soon
.[this comment previously talked about ASYNC111, but async support for 111 was already implemented at the time of posting :confused: ]
- [ ] ASYNC113: https://docs.python.org/3/library/asyncio-task.html#asyncio.create_task is not an async method, so it's vulnerable to the same problem as
start_soon
.
One part that leaves me somewhat confused about implementing ASYNC113 is what, if anything, to do about ASYNC114. Currently we gate ASYNC113 to only warn on startable methods, presumably to reduce false positives when you don't care about the background task being properly up and running. But I don't think there's any way to differentiate those for asyncio tasks, so we're left with the options of:
startable_in_context_manager
.If startable_in_context_manager
was expanded to support wildcards, we could get the best of both worlds by telling asyncio users to specify *
if they want the former behaviour. (this would also allow anyio/trio users to go maximum defensiveness, in case they're starting functions not defined in code that could trigger ASYNC114, or they might've forgotten to add task_status
to functions)
Another problem is that since there's no .start()
-equivalent that guarantees that the task has been started, there's no standardized way of alleviating the problem that we could detect, so users are left to handle it in whatever way they can, and then noqa
the warning.
Could also consider supporting curio or any other IO library.