26 ms·

Django 4.1

289 points by j4mie 4y ago

buro9 4y ago
Guess I best upgrade my production side-project from Django 1.5.9
- mafro 4y ago
  No need, that's a good vintage.
  - wellthisisgreat 4y ago
    chef’s kiss
- collinmanderson 4y ago
  Python 2 or 3?
  - buro9 4y ago
    There's a Python 3? It's 2... definitely 2.
    - intrestingstuff 4y ago
      you found the sweet spot
- icedchai 4y ago
  You're giving me nightmares. I used to work for a company stuck on Python 2.7 and Django 1.something. They're still on it today.
  - buro9 4y ago
    I'll qualify mine by pointing out that it doesn't have a database and is just a web client, a veneer, over a very secure API that really does all of the work. The Django I use is nothing but a template rendering thing.
    - icedchai 4y ago
      Sounds like a perfect app for PHP.
sirodoht 4y ago
I wonder how popular the async interface will become. I use Python and Django extensively but haven't touch any of the async operations.
- jonatron 4y ago
  Once the underlying database queries become async, I can see it becoming popular. Many views do multiple database queries that aren't dependent on each other, which would be a quick win to make async.
- Chiron1991 4y ago
  Since ultimately anything you build in Django will eventually go into the ORM layer, it won't become anything unless the ORM is fully async. This release brings the async API to it, but: > Note that, at this stage, the underlying database operations remain synchronous That kinda defeats the whole purpose of an ASGI app.
  - 0xDEFACED 4y ago
    >That kinda defeats the whole purpose of an ASGI app. Unless I’m missing something, wouldn’t an async ORM provide significant benefit for apps with an internet-based DB connection? I would think the underlying DB ops would be much faster than sending a request and waiting on a response.
  - tecleandor 4y ago
    But you could use it for load not tied to database, isn't it? Like CPU, IO or network bound stuff...
    - aynyc 4y ago
      You don't use async for CPU. Python async is actually asyncio, so I/O and network such as calling external API, etc.. It'll make integration much easier to reason about.
- Piezoid 4y ago
WhatsName 4y ago
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. 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.
- syrusakbary 4y ago
  I completely agree. I have been using GraphQL in Django with WebSockets and ASGI and it was a bit of pain in the ass to get everything working, but with this changes things will get much smoother. Great work Django team!
- WhyNotHugo 4y ago
  Also, async views allow for better scaling. Say your view needs to make an API call to a third party service within a request-response cycle. Currently, this will block an entire worker/thread while doing a blocking request. With async, we can use async HTTP libraries and scale these WAY better.
  - BozeWolf 4y ago
    Or just run 20 workers and let the OS handle async. OSes are pretty good at this. Async is pretty hard to reason about. Async is beneficial when you make multiple blocking (http) request to a resource at the same time and later fold that into one response. Parallel stuff. Or when you are forced to run a single thread. Or when you are memory bound. Reality is that most requests depend on previous requests quite often. In the latter case there is no benefit in terms of speed for the user. I know this is unpopular opinion though :-)
    - ramraj07 4y ago
      Might be unpopular but still good to stick to it. I tend to associate excessive enthusiasm for pythons async await framework as a sign of immaturity and potential for doing things without understanding them fully. I’d never trust async code from anyone except the best python engineers. Most of them out there can’t even debug linear code, adding async to the mix only makes it worse. At least you can trust the time stamps.
nickjj 4y ago
If anyone is interested I updated my example Django Docker app to 4.1 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example It includes running Django, Celery, gunicorn, Postgres, Redis, esbuild and Tailwind through Docker and Docker Compose. It's set up for development and production.
- fredsmith219 4y ago
  This is very cool. Thank you.
- akx 4y ago
  That seems to be using WSGI, not ASGI, though, so no natively `async` views..?
  - nickjj 4y ago
    > That seems to be using WSGI, not ASGI, though, so no natively `async` views..? One does not simply go async. Changing your entire app to go full async has serious implications, requires every library you use to support it and requires a completely different mode of thinking. The example project includes an ASGI file if you want to use an async app server like uvicorn with async views instead of gunicorn. That would involve changing a couple of lines of code. That's very much a "per user" decision and in my opinion shouldn't be the default for the project when 4.1 only landed a few hours ago. It's going to take a long time until apps are ready to go async by default, both from waiting on libraries to support it and the community to shift towards this style of building apps.
    - akx 4y ago
      I know one does not simply go async, sure, but I thought it should be noted (especially considering how async-centric this release is) that the repo doesn't immediately allow for async. Also, "4.1 only landed a few hours ago" isn't the perfect argument in my books since support for ASGI and async views in general was added back in 3.0 and 3.1: * https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-support https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-sup... * https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchronous-views-and-middleware-support https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchro...
game_the0ry 4y ago
Am I bad SWE if I do not care for for async in django? 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. FWIW I like django / python for a lot of things, just not for performance.
- _hcuq 4y ago
  It obviously has it’s used, but I have never needed async in my 17 years as a web programmer…
- bastawhiz 4y ago
  Async doesn't make your code faster, though there are cases where it lets you handle more requests with a single server (especially if you have code that is async). But moreover, if you have libraries that use async code, it's really not ideal if the thing that runs those libraries isn't async. You don't have to like or want it, but it's there for the folks who want or need it.
- ralmidani 4y ago
  Enabling async means those already invested in Django can do more on one machine without a complete rewrite, and those considering it can adopt it with fewer reservations. There will always be more scalable platforms out there, but enabling async with Django helps it serve the “sweet spot” in terms of both ergonomics and scalability.
  - roflyear 4y ago
    Probably not. If you need async for DB "stuff" to take advantage of your resources, I think it is a rare thing, and likely you would not want to use the ORM anyway, and then can just do whatever you want without it.
- rossdavidh 4y ago
  If you have one part of your app that needs async, but 90% of it is in the sweet spot for Django, then this could be important.
ac130kz 4y ago
Let's see how long it will take for DRF to support async...
ralmidani 4y ago
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.
- brianbreslin 4y ago
  as someone who is re-learning to code now after a 15 year absence, django is for sure making it feel amazing. Sometimes folks in this community overthink normal people's actual needs when it comes to programming tools, Django seems to support most everyday uses just fine.
- zem 4y ago
  i have dabbled with web programming several times in the past, with a variety of frameworks (sinatra, rails, phoenix, fastapi, and now django). django is the first time i have felt truly productive - its architecture is the perfect balance between sinatra (doesn't do enough) and rails/phoenix (where i keep getting lost in a maze of generated code). also the orm really gets out of your way.
  - _hcuq 4y ago
    I agree. Django is the only framework that makes sense to me. I have been doing web programming full time since 2006, using only vanilla code ( there were no frameworks back then). Django is the only framework that tempts me.
BiteCode_dev 4y ago
This is going to make django-ninja even easier to use, so it's very welcome. And if you like django and never tried django ninja, it's like DRF and FastAPI had a baby: https://django-ninja.rest-framework.com/ https://django-ninja.rest-framework.com/. You define your endpoints using pydantic type hints, and it generates the API, validators and docs all in one go.
- pen2l 4y ago
  Django is supposed to be opinionated and batteries-included, Django Software Foundation ought to shepherd some REST package. There's ninja, DRF, etc. and a few more on the horizon. I agree with the other poster, RESTful projects with views one encounters: often complicated and not easily maintainable. DSF should take over django-ninja. :)
- godtoldmetodoit 4y ago
  +1 on Ninja. Been using it on a number of projects the last 6 months, and its been a joy to use.
zzzeek 4y ago
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. 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. 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.
- baq 4y ago
  thanks for sqlalchemy. it's a shining star in the Python package ecosystem. > 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. do you have a blog post or some other kind of writeup to read about it? maybe nobody else had the same idea and it works so well nobody is aware that it can be done...
  - tmpz22 4y ago
    Is it a shining star or a rough dirty pragmatic get-the-job-done tool with a heart of gold thats approachable to newcomers and grizzled veterans alike. The trenches are too dirty for shining stars.
  - zzzeek 4y ago
    I was a bit ranty but the gist at https://gist.github.com/zzzeek/d9c98c43553e43e76600f03dfb5e1af2 https://gist.github.com/zzzeek/d9c98c43553e43e76600f03dfb5e1... lays out pretty much everything that happened.
hansonkd13 4y ago
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. 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. 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. However I think gevent in the past was the crutch that prevented a lot of lib authors from writing async libs.
- aobdev 4y ago
  Hey, I wanted to chime in and say that I too am underwhelmed with the support for async in Python libs. Coming from a node.js background, it falls short because you constantly have to think about whether async code is calling sync code, or vice versa, and whether you need an executor, threadpool, etc. Just a mess that gets in the way of productivity IMO. However, things have been getting better, and in case you haven't seen it, AIORedis[0] appears to be the de facto standard for async in Python (a little better with 1,724,389 downloads this month). It's popular enough that it's been merged with the official redis-py driver[1]. [0] https://aioredis.readthedocs.io/en/latest/ https://aioredis.readthedocs.io/en/latest/ [1] https://github.com/redis/redis-py/releases/tag/v4.2.0rc1 https://github.com/redis/redis-py/releases/tag/v4.2.0rc1
- collinmanderson 4y ago
  Yes, though I do think the python async ecosystem is gradually moving from a "3rd class citizen" to a "2nd class citizen". There are sync+async libraries like HTTPX that are gaining support. I don't expect it to really ever be a "1st class citizen" (supported as well as sync in pretty much every library everywhere) because of backward compatibility and ultimately async is just harder to program. Sometimes developer time is more important than the performance wins of async.
syastrov 4y ago
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.
- dmart 4y ago
  Except DRF doesn’t call clean() anymore (as of 3.0?), so you have to reimplement all your validation logic in your serializers anyway. Always seemed like a huge mistake to me for a framework that’s supposed to feel like a natural extension of Django.

Django 4.1

289 points by j4mie 4y ago

buro9 4y ago

Guess I best upgrade my production side-project from Django 1.5.9

mafro 4y ago
No need, that's a good vintage.
- wellthisisgreat 4y ago
  chef’s kiss
collinmanderson 4y ago
Python 2 or 3?
- buro9 4y ago
  There's a Python 3? It's 2... definitely 2.
  - intrestingstuff 4y ago
    you found the sweet spot
icedchai 4y ago
You're giving me nightmares. I used to work for a company stuck on Python 2.7 and Django 1.something. They're still on it today.
- buro9 4y ago
  I'll qualify mine by pointing out that it doesn't have a database and is just a web client, a veneer, over a very secure API that really does all of the work. The Django I use is nothing but a template rendering thing.
  - icedchai 4y ago
    Sounds like a perfect app for PHP.

sirodoht 4y ago

I wonder how popular the async interface will become. I use Python and Django extensively but haven't touch any of the async operations.

jonatron 4y ago
Once the underlying database queries become async, I can see it becoming popular. Many views do multiple database queries that aren't dependent on each other, which would be a quick win to make async.
Chiron1991 4y ago
Since ultimately anything you build in Django will eventually go into the ORM layer, it won't become anything unless the ORM is fully async. This release brings the async API to it, but: > Note that, at this stage, the underlying database operations remain synchronous That kinda defeats the whole purpose of an ASGI app.
- 0xDEFACED 4y ago
  >That kinda defeats the whole purpose of an ASGI app. Unless I’m missing something, wouldn’t an async ORM provide significant benefit for apps with an internet-based DB connection? I would think the underlying DB ops would be much faster than sending a request and waiting on a response.
- tecleandor 4y ago
  But you could use it for load not tied to database, isn't it? Like CPU, IO or network bound stuff...
  - aynyc 4y ago
    You don't use async for CPU. Python async is actually asyncio, so I/O and network such as calling external API, etc.. It'll make integration much easier to reason about.
Piezoid 4y ago

WhatsName 4y ago

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. 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.

syrusakbary 4y ago
I completely agree. I have been using GraphQL in Django with WebSockets and ASGI and it was a bit of pain in the ass to get everything working, but with this changes things will get much smoother. Great work Django team!
WhyNotHugo 4y ago
Also, async views allow for better scaling. Say your view needs to make an API call to a third party service within a request-response cycle. Currently, this will block an entire worker/thread while doing a blocking request. With async, we can use async HTTP libraries and scale these WAY better.
- BozeWolf 4y ago
  Or just run 20 workers and let the OS handle async. OSes are pretty good at this. Async is pretty hard to reason about. Async is beneficial when you make multiple blocking (http) request to a resource at the same time and later fold that into one response. Parallel stuff. Or when you are forced to run a single thread. Or when you are memory bound. Reality is that most requests depend on previous requests quite often. In the latter case there is no benefit in terms of speed for the user. I know this is unpopular opinion though :-)
  - ramraj07 4y ago
    Might be unpopular but still good to stick to it. I tend to associate excessive enthusiasm for pythons async await framework as a sign of immaturity and potential for doing things without understanding them fully. I’d never trust async code from anyone except the best python engineers. Most of them out there can’t even debug linear code, adding async to the mix only makes it worse. At least you can trust the time stamps.

nickjj 4y ago

If anyone is interested I updated my example Django Docker app to 4.1 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example It includes running Django, Celery, gunicorn, Postgres, Redis, esbuild and Tailwind through Docker and Docker Compose. It's set up for development and production.

fredsmith219 4y ago
This is very cool. Thank you.
akx 4y ago
That seems to be using WSGI, not ASGI, though, so no natively `async` views..?
- nickjj 4y ago
  > That seems to be using WSGI, not ASGI, though, so no natively `async` views..? One does not simply go async. Changing your entire app to go full async has serious implications, requires every library you use to support it and requires a completely different mode of thinking. The example project includes an ASGI file if you want to use an async app server like uvicorn with async views instead of gunicorn. That would involve changing a couple of lines of code. That's very much a "per user" decision and in my opinion shouldn't be the default for the project when 4.1 only landed a few hours ago. It's going to take a long time until apps are ready to go async by default, both from waiting on libraries to support it and the community to shift towards this style of building apps.
  - akx 4y ago
    I know one does not simply go async, sure, but I thought it should be noted (especially considering how async-centric this release is) that the repo doesn't immediately allow for async. Also, "4.1 only landed a few hours ago" isn't the perfect argument in my books since support for ASGI and async views in general was added back in 3.0 and 3.1: * https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-support https://docs.djangoproject.com/en/4.0/releases/3.0/#asgi-sup... * https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchronous-views-and-middleware-support https://docs.djangoproject.com/en/4.0/releases/3.1/#asynchro...

game_the0ry 4y ago

Am I bad SWE if I do not care for for async in django? 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. FWIW I like django / python for a lot of things, just not for performance.

_hcuq 4y ago
It obviously has it’s used, but I have never needed async in my 17 years as a web programmer…
bastawhiz 4y ago
Async doesn't make your code faster, though there are cases where it lets you handle more requests with a single server (especially if you have code that is async). But moreover, if you have libraries that use async code, it's really not ideal if the thing that runs those libraries isn't async. You don't have to like or want it, but it's there for the folks who want or need it.
ralmidani 4y ago
Enabling async means those already invested in Django can do more on one machine without a complete rewrite, and those considering it can adopt it with fewer reservations. There will always be more scalable platforms out there, but enabling async with Django helps it serve the “sweet spot” in terms of both ergonomics and scalability.
- roflyear 4y ago
  Probably not. If you need async for DB "stuff" to take advantage of your resources, I think it is a rare thing, and likely you would not want to use the ORM anyway, and then can just do whatever you want without it.
rossdavidh 4y ago
If you have one part of your app that needs async, but 90% of it is in the sweet spot for Django, then this could be important.

ac130kz 4y ago

Let's see how long it will take for DRF to support async...

ralmidani 4y ago

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.

brianbreslin 4y ago
as someone who is re-learning to code now after a 15 year absence, django is for sure making it feel amazing. Sometimes folks in this community overthink normal people's actual needs when it comes to programming tools, Django seems to support most everyday uses just fine.
zem 4y ago
i have dabbled with web programming several times in the past, with a variety of frameworks (sinatra, rails, phoenix, fastapi, and now django). django is the first time i have felt truly productive - its architecture is the perfect balance between sinatra (doesn't do enough) and rails/phoenix (where i keep getting lost in a maze of generated code). also the orm really gets out of your way.
- _hcuq 4y ago
  I agree. Django is the only framework that makes sense to me. I have been doing web programming full time since 2006, using only vanilla code ( there were no frameworks back then). Django is the only framework that tempts me.

BiteCode_dev 4y ago

This is going to make django-ninja even easier to use, so it's very welcome. And if you like django and never tried django ninja, it's like DRF and FastAPI had a baby: https://django-ninja.rest-framework.com/ https://django-ninja.rest-framework.com/. You define your endpoints using pydantic type hints, and it generates the API, validators and docs all in one go.

pen2l 4y ago
Django is supposed to be opinionated and batteries-included, Django Software Foundation ought to shepherd some REST package. There's ninja, DRF, etc. and a few more on the horizon. I agree with the other poster, RESTful projects with views one encounters: often complicated and not easily maintainable. DSF should take over django-ninja. :)
godtoldmetodoit 4y ago
+1 on Ninja. Been using it on a number of projects the last 6 months, and its been a joy to use.

zzzeek 4y ago

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. 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. 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.

baq 4y ago
thanks for sqlalchemy. it's a shining star in the Python package ecosystem. > 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. do you have a blog post or some other kind of writeup to read about it? maybe nobody else had the same idea and it works so well nobody is aware that it can be done...
- tmpz22 4y ago
  Is it a shining star or a rough dirty pragmatic get-the-job-done tool with a heart of gold thats approachable to newcomers and grizzled veterans alike. The trenches are too dirty for shining stars.
- zzzeek 4y ago
  I was a bit ranty but the gist at https://gist.github.com/zzzeek/d9c98c43553e43e76600f03dfb5e1af2 https://gist.github.com/zzzeek/d9c98c43553e43e76600f03dfb5e1... lays out pretty much everything that happened.

hansonkd13 4y ago

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. 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. 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. However I think gevent in the past was the crutch that prevented a lot of lib authors from writing async libs.

aobdev 4y ago
Hey, I wanted to chime in and say that I too am underwhelmed with the support for async in Python libs. Coming from a node.js background, it falls short because you constantly have to think about whether async code is calling sync code, or vice versa, and whether you need an executor, threadpool, etc. Just a mess that gets in the way of productivity IMO. However, things have been getting better, and in case you haven't seen it, AIORedis[0] appears to be the de facto standard for async in Python (a little better with 1,724,389 downloads this month). It's popular enough that it's been merged with the official redis-py driver[1]. [0] https://aioredis.readthedocs.io/en/latest/ https://aioredis.readthedocs.io/en/latest/ [1] https://github.com/redis/redis-py/releases/tag/v4.2.0rc1 https://github.com/redis/redis-py/releases/tag/v4.2.0rc1
collinmanderson 4y ago
Yes, though I do think the python async ecosystem is gradually moving from a "3rd class citizen" to a "2nd class citizen". There are sync+async libraries like HTTPX that are gaining support. I don't expect it to really ever be a "1st class citizen" (supported as well as sync in pretty much every library everywhere) because of backward compatibility and ultimately async is just harder to program. Sometimes developer time is more important than the performance wins of async.

syastrov 4y ago

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.

dmart 4y ago
Except DRF doesn’t call clean() anymore (as of 3.0?), so you have to reimplement all your validation logic in your serializers anyway. Always seemed like a huge mistake to me for a framework that’s supposed to feel like a natural extension of Django.