looking at the release notes and the source, it looks like the asyncio interface is still using the old drivers, like psycopg2 for postgresql, and using a threadpool.<p>we at SQLAlchemy came up with a way to interface asyncio frontend and backend (like asyncpg for the driver) while maintaining all the "in the middle" code as synchronous style. the dark secret is that for this approach you have to use greenlet to propagate the "await" operations. It's been in our release for 18 months now with 1M downloads a day and there have been no problems reported with it, so i continue to wonder why nobody else seems to want to look at this approach. one downside which nobody has complained about yet is that it makes profiling tools like cProfile harder to use, but seems not to have come up yet.<p>there's also another approach, which is that you rewrite all your "in the middle" code as pure asyncio, then create a dummy task to implement your synchronous API. dark secret for that one is you had to rewrite everything and I'm not sure if there's other performance implications for having awaits all throughout code that's running only one task per thread.
If anyone is interested I updated my example Django Docker app to 4.1 at: <a href="https://github.com/nickjj/docker-django-example" rel="nofollow">https://github.com/nickjj/docker-django-example</a><p>It includes running Django, Celery, gunicorn, Postgres, Redis, esbuild and Tailwind through Docker and Docker Compose. It's set up for development and production.
Great to see improving support for async here. I am a big fan, but IMO python async code is just different from other async langauges. I used async extensively in python and compared to other languages it is a pain to use because unless 100% of the the libs you want support it you will get stuck on some sync library. Async in python is not even a 2nd class citizen. Its more like a 3rd class citizen. Its gets better every year but it is minuscule compared to regular sync code, so very few tutorials mention it and nobody teaches it as the default way of doing things.<p>In order for async to be popular it needs to be the default way of writing python. Right now its an after thought for writing “high performance” python. For example asyncio version of redis got 72,114 downloads this month. The sync version got 26,825,663. Thats not even in the same universe.<p>Historically, using something like gevent is a more drop-in solution for python if you want lightweight threads, but it comes with its own problems. Gevent gives python what Zig has that automatically turns all sync IO calls to async and your app is now magically using greenthreads.<p>However I think gevent in the past was the crutch that prevented a lot of lib authors from writing async libs.
The most anticipated Django release for me personally. Async ORM access is a massive quality of life improvememt, same for async CBV. The later is also a blocker for Django Rest Framework going async.<p>Sure most CRUD applications work perfectly fine using WSGI, but for anyone using other protocols like WS or MQTT in their app this is kind of a big deal.
This is going to make django-ninja even easier to use, so it's very welcome.<p>And if you like django and never tried django ninja, it's like DRF and FastAPI had a baby: <a href="https://django-ninja.rest-framework.com/" rel="nofollow">https://django-ninja.rest-framework.com/</a>. You define your endpoints using pydantic type hints, and it generates the API, validators and docs all in one go.
Django is single-handedly responsible for making me fall in love with programming. I am now using Elixir/Phoenix and 100% sold on the benefits of working with immutable data, but I still keep an eye on developments in the Python/Django ecosystem. Seeing Django edge closer to having a fully async stack is very exciting, and should make it a more viable platform for existing users as well as newcomers.
Am I bad SWE if I do not care for for async in django?<p>I am sure a a lot of django devs will like it, but if I need the performance that I would get from going async, I would not being using django as my web framework.<p>FWIW I like django / python for a lot of things, just not for performance.
There are a lot of comments about async ORM, but to me the support for application-level (e.g. if you use forms, admin, DRF, Graphene) validation of DB-level constraints is a super cool feature that solves a real pain point - having to duplicate this logic at both levels, or forgetting to do so.