Repository navigation
Rule for async without await #339
Description
Hi, I'm wondering what you think about adding a rule to catch async functions that have no await statements - and which could therefore be changed into sync functions for a small performance and simplicity gain.
It could work in the same way as this no-async-without-await rule in TSLint: https://palantir.github.io/tslint/rules/no-async-without-await/#:~:text=Marking%20a%20function%20as%20async,keyword%20is%20there%20by%20mistake.
Of course there may be instances where a function needs to be async to satisfy some external interface. But in all other cases, it would be useful to have a way to scan for pointless async functions.
I don't think an auto-fix would be very simple since the call sites also need to be updated, but flagging as a warning for manual fixing would be helpful.
Activity
jakkdl commentedon Jan 21, 2025
This kind of exists in the form of ASYNC910, though that will flag a lot more than just functions without
awaitand so might not be relevant for you.Ruff does have unused-async, though you'll need to run with
--previewto get it.Agree that autofix is not really on the table.
But I'm not opposed to adding it to flake8-async itself, and even for ruff it kind of fits better among the other async rules than randomly among their own. Implementing it should be straightforward, only complication would be if we want it to interact with ASYNC9xx and suppress ASYNC9xx if async-no-await is raised.
@Zac-HD for a second opinion
ryanc-bs commentedon Jan 21, 2025
Thanks, I did not know about RUF029. Something I noticed while trying that is that is only seems to work for simple functions and not for methods on a class - would be great to be able to lint both of these.
Zac-HD commentedon Jan 21, 2025
jakkdl commentedon Jan 22, 2025
I suppose we could have two rules then, one for functions and one for class methods, with accompanying blurbs about their optional-ness.
TeamSpen210 commentedon Jan 23, 2025
One other situation that might be worth excluding is functions with decorators applied, since those probably also expect a specific interface. Although of course many don't or are adaptive between sync/async.
jakkdl commentedon Jan 23, 2025
uh... turns out there's already a ~finished PR implementing this 🙃
#309
and #253 as the associated issue
jakkdl commentedon Jan 24, 2025
Past me concluded there's a "cray false alarm rate" for class methods, so I'll stick with only doing this for functions.
If you really do want this you could run ASYNC910/ASYNC911 as a one-off.
#309 has support for no-checkpoint-warning-decorators for decorators where you want to suppress 910, 911, and 124 :)