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

71–80 of 126 posts

Re: Django 4.1

#71

Post by hansonkd13 »

coldtea wrote: post #62
ramraj07 wrote: post #9

Earlier quoted context omitted.

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"?

I think my experience in async in other languages has shown how rough async in Python is.

Unless async is the default python, it will always be an after thought and introduce needless complexity when working on large projects that require a lot of external libs.

Re: Django 4.1

#72

Post by collinmanderson »

WhatsName wrote: post #5

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.

> for anyone using other protocols like WS

Yes, if you do WebSockets, async really is a must if you don't want to have one thread per active connection. Each thread takes 8mb of virtual memory, not sure how much actual memory.

It's also nice for a backend that's doing a lot of proxying apis to another backend.

Re: Django 4.1

#73

Post by blitzar »

nickjj wrote: post #16
akx wrote: post #13

Earlier quoted context omitted.

That seems to be using WSGI, not ASGI, though, so no natively `async` views..?

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

Never go full async

Re: Django 4.1

#74

Post by hansonkd13 »

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.

Re: Django 4.1

#75

Post by aynyc »

Ralfp wrote: post #50
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?

exactly, it fires database call in a separare thread with coroutine awaiting this threads result.

Is the limitation on django ORM? Because I can run asyncpg/psycopg3 and sqlalchemy with async mode without any issues.

Re: Django 4.1

#76

Post by fernandotakai »

chpmrc wrote: post #29
tgv wrote: post #20

Earlier quoted context omitted.

Seriously: why use Django for a REST-like service? I inherited an application that (probably) evolved from form-based to REST with a JS frontend, and I fail to see the point. There's a model, a serializer, handlers to implement relations, and multiple views per data type . It's so much overhead, and everything has to be kept in sync.

If I had a dollar for every time I heard this I would be having lunch with Jeff Bezos right now.

every python developer has accidentally made django at least once.

you start with "i will do in flask because it's easier". then you need to add authorization/authentication. and then templating, ORM, maybe some RESTful flask library to make endpoints a bit easier... and now you have django, but in a different way.

Re: Django 4.1

#77

Post by pen2l »

BiteCode_dev wrote: post #63

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.

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

Re: Django 4.1

#78

Post by aobdev »

hansonkd13 wrote: post #74

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

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/

[1] https://github.com/redis/redis-py/releases/tag/v4.2.0rc1

Re: Django 4.1

#79

Post by pen2l »

collinmanderson wrote: post #58
tgv wrote: post #20

Earlier quoted context omitted.

Seriously: why use Django for a REST-like service? I inherited an application that (probably) evolved from form-based to REST with a JS frontend, and I fail to see the point. There's a model, a serializer, handlers to implement relations, and multiple views per data type . It's so much overhead, and everything has to be kept in sync.

Why do a REST-like service? It makes sense as backend for a native iOS/Android app, and if you already have that REST endpoint then it can make sense to re-use it for the web-version of your app. But if you're not doing an iOS/Android app (most websites?), then I generally agree it's a lot more work compared to form-based / server-side-templates (though sometimes can give a _slightly_ better user experience, _if_ don…

In this day and age, mobile apps are _almost_ a must so REST is everywhere.

A well-implemented REST app is pretty nice, business logic divorced from all UI and API lends itself nicely as a comfortable and maintainable programming environment. More often than not, being RESTful from the get-go tends to have positive returns down the line.

Post reply on HN