Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 4.1

djangoproject.com

Post reply on HN
Print view View original

61–70 of 126 posts

Re: Django 4.1

#61

Post by brianbreslin »

ralmidani wrote: post #56

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.

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.

Re: Django 4.1

#62

Post by coldtea »

ramraj07 wrote: post #9
BozeWolf wrote: post #7

Earlier quoted context omitted.

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

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 sta…

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

Couldn't it be the inverse? I.e. your inexeperience with async code in other languages, and not understanding it fully, translating into "new thing aversion"?

Re: Django 4.1

#63

Post by BiteCode_dev »

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/. You define your endpoints using pydantic type hints, and it generates the API, validators and docs all in one go.

Re: Django 4.1

#64

Post by nilsbunger »

Demiurge wrote: post #51
game_the0ry wrote: post #34

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.

No, I agree with you. It's 2022 and I have thought only once that it would be neat to have async methods from Django, but only as some 'cool thing to try'. I don't actually actually know if there would be any substantial benefit. It's like when I tried PyPy as my django interpreter. It gave a few percent speed increase in "real world" but created extra work for deployment. I've been using Django non-stop from 0.96, a…

> If I was running a trading clearing house, or Instagram, I'd probably care about marginal improvements, and then use another language.

Ha, Instagram was written in Django!

Re: Django 4.1

#65

Post by hansonkd13 »

megaman821 wrote: post #52
aynyc wrote: post #48

Earlier quoted context omitted.

I don't fully understand the sync_to_async() operation here. So the underlying database is not async, then is Django just tossing the sync DB call onto a thread or something?

Yes, it is just being put on a thread. A future Django release will use async database drivers. Django is very incrementally adding support for async. I don't believe they have started work on async templates yet, which will be one of the last major areas before the framework is fully async.

Why do they need Async templates? When a template renders it should be pure data and fully on the CPU. It seems Async templates would encourage a bad behavior of doing n+1 queries inside the HTML.

Re: Django 4.1

#66

Post by collinmanderson »

nickjj wrote: post #36
VWWHFSfQ wrote: post #26

Earlier quoted context omitted.

> use an async app server like uvicorn with async views instead of gunicorn I believe gunicorn with the uvicorn worker class is the recommended production server. > For production deployments we recommend using gunicorn with the uvicorn worker class. https://www.uvicorn.org/#running-with-gunicorn

> I believe gunicorn with the uvicorn worker class is the recommended production server. Yep for production that works. In development tho I don't think the gunicorn --reload flag works with that worker type. There is an issue open for this at https://github.com/benoitc/gunicorn/issues/2339 and since I last tried about a year ago I guess they have an unofficial "workaround solution" in one of the comments but it invo…

Interesting looks like it might actually be a python bug. Somehow just changing from sys.exit(0) -> os._exit(0) apparently fixes it.

"There is a problem with using the sys.exit() in a forked process (child processes or workers) instead of using the os._exit() that is mentioned in python documentation."

https://github.com/benoitc/gunicorn/pull/2820

I've always just needed to manually reload the gunicorn async server in development. Super annoying.

Re: Django 4.1

#67

Post by megaman821 »

hansonkd13 wrote: post #65
megaman821 wrote: post #52

Earlier quoted context omitted.

Yes, it is just being put on a thread. A future Django release will use async database drivers. Django is very incrementally adding support for async. I don't believe they have started work on async templates yet, which will be one of the last major areas before the framework is fully async.

Why do they need Async templates? When a template renders it should be pure data and fully on the CPU. It seems Async templates would encourage a bad behavior of doing n+1 queries inside the HTML.

My immediate thought would be custom template tags. Like `{% popular_articles %}` would have to connect to the DB and load the articles. I am sure there are other reasons too.

Re: Django 4.1

#68

Post by collinmanderson »

nilsbunger wrote: post #64
Demiurge wrote: post #51

Earlier quoted context omitted.

No, I agree with you. It's 2022 and I have thought only once that it would be neat to have async methods from Django, but only as some 'cool thing to try'. I don't actually actually know if there would be any substantial benefit. It's like when I tried PyPy as my django interpreter. It gave a few percent speed increase in "real world" but created extra work for deployment. I've been using Django non-stop from 0.96, a…

> If I was running a trading clearing house, or Instagram, I'd probably care about marginal improvements, and then use another language. Ha, Instagram was written in Django!

Right, though they're stuck on 1.8 (upgraded to 1.8 only so they could use python3), and really just use it for request/response/views, not ORM or anything else.

Re: Django 4.1

#70

Post by zzzeek »

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.

Post reply on HN