Finally I think I do have the right edition of this in my mind. Yes, it can (and should) be done as a 3rd party project since it totally breaks the compatibility. I will call it vinyl.
The project will be a fork of django 4.2. The main idea is to add “async” and “await” everywhere throughout the codebase. However, it will refuse from the start any compatibility with django. So, “the API facade” that I was proposing above, won’t be required.
A taste of the future API:
await queryset
await obj.related_obj
async for obj in queryset2:
await obj.save()
Every fetching will require an await, so iterating an unfetched queryset will result in an error. The rest will be pretty familiar for django users. An interesting detail: when no fetching is required, the existing django code/syntax will work!
The vinyl framework will be async-first without doubt. But it won’t be async-only.
It will be possible to use blocking I/O with vinyl, and to deploy as a WSGI app. The views in the app will be async functions anyway. But, in the case of blocking I/O, they will be treated as just generators (and those generators will never yield).
Why do I need to support WSGI? First: I don’t want to provide all the async db backends at once all by myself. Second: because I want to reuse the existing django testsuite, I need tested db backends, which currently don’t exist. In other words, I need to get past the chicken an egg problem. As a result, my framework, vinyl, will be passing tests and so, production ready, from day 1. There is no doubt however, that it’s asyncio that will be used in 95% cases or so.
To summarize: I am going to build vinyl framework that will be a django fork. The bulk of the changes will be just adding “async” and “await” everywhere. It will support both blocking and async I/O with a single codebase and with a single API.
I am sure django will soon become legacy and all the new features will be developed for vinyl.
What do you think?@andrewgodwin @charettes @adamchainz @carltongibson @felixxm @apollo13