Asyncifying django.contrib.auth? (and signals, and maybe sessions)

Django Internals Async
29

I’m currently a bit sceptical about extending async very much further into the contrib modules, due to the limited need/benefit, and the large amount of duplication we run into due to the function color problem

Yeah totally, that’s one of the things I called out at the very beginning of this process:

B. Are there proven strategies for reducing code duplication between sync and async versions of functionality in Django or in Python broadly?..

My reading of DEP009 is that the extended goal of async django is to replace all the sync code with async wrappers eventually, so I was just hacking away on that goal. I was specifically thinking about these lines in that DEP:

The overall goal is to have every single part of Django that could be blocking -that is, which is not just simple CPU-bound computation - be async-native (run in an asynchronous event loop without blocking).
This includes features like:

  • Middleware
  • Views
  • The ORM
  • Templating
  • Testing
  • Caching
  • Form validation
  • Emails

If that DEP is no longer current I’d be eager to read what has superseded it!

It’s certainly more intimidating but ORM-native wrappers around async DB connections, and streaming queries, and so on strike me as something that’s going to yield much better returns.

Yeah I just feel a bit too intimidated to get started on that right now, but maybe it is time to give it a closer look!

1 Like