Thank you for your reply.
Thanks for the reminder, maybe we should discuss this at Asyncifying django.contrib.auth? (and signals, and maybe sessions) - #5 by bigfootjon.
I would like to explain my views on asynchrony. I think the main benefit of async is that io will no longer block the thread, so it can improve Django’s performance.
Therefore, if we say what interfaces we need to asynchronize, I think the answer is that most of the interfaces that involve io, unless the cost of asynchronizing some interfaces is very high, they should be asynchronized.
Another thing is about why AbstractBaseUser.check_password() needs to be asynchronized. I think what you said makes sense, if we simply change the password, then we can do it in a synchronized view. But in the default AUTHENTICATION_BACKENDS, namely ModelBackend, check_password() will be called in the authenticate function. If PASSWORD_HASHERS happens to be modified in an asynchronous context, an exception may be raised.
In fact, in Django ticket #39102, in order to avoid this exception, the sync_to_async method is used to wrap auth.get_user. But I think using sync_to_async is only a temporary solution, because auth.get_user is a very frequently called function, and the asynchronous implementation using threads is not as high as native asynchronous performance after all, so we should eventually implement a native asynchronous version for auth.get_user.
If that’s what I said, it would make sense to add asynchronous support to AbstractBaseUser.check_password(), since this is the first step towards a natively asynchronous auth.get_user.