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

101–110 of 126 posts

Re: Django 4.1

#101

Post by syastrov »

zzzeek wrote: post #70

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

Someone mentioned it on a Django forum thread about async ORM [0]. It seems to have been ignored. Super cool idea and execution! I hope it gets some more exposure.

[0] https://forum.djangoproject.com/t/asynchronous-orm/5925/51

Re: Django 4.1

#102

Post by codethief »

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…

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

Might this have to do with the fact that the (lack of) performance of asyncio is exactly the issue here?

I remember reading a blog post by zzzeek (the SQLAlchemy author who's also participating in our discussion here) about precisely this issue a while ago. Not sure but it might have been this one:

https://techspot.zzzeek.org/2015/02/15/asynchronous-python-a...

Re: Django 4.1

#103

Post by bredren »

zzzeek wrote: post #70

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

Mike, thanks for this reply and your work on SQLAlchemy. My employer uses your framework, but not yet the newest versions featuring async.

Previously, and still in my personal projects, I have been a Django and Django ORM person.

I got away with by and large avoiding SQL statements in building web apps and have sometimes struggled to understand why SQL statements seemed much more forward-facing in SQLAlchemy in comparison.

Then I listened to your recent Talk Python podcast episode with M. Kennedy [1] and it helped me understand where the framework is coming from with regards to expectations for SQL capability from a developer that wants to use SQLAlchemy.

I believe the focus was much more so on the dark secrets you mention above, though and colored in how you discovered those.

If anyone wants to learn more about async or SQLAlchemy, I highly recommend listening.

As an aside, it was also cool to hear you talking about your project because for me, it humanized you as the maintainer. You sounded pretty chill, which was for some reason not what I was expecting.

I hope you can make it back on to that podcast with less of a gap between appearances next time.

[1] https://talkpython.fm/episodes/show/344/sqlalchemy-2.0

Re: Django 4.1

#104

Post by physicsguy »

larrik wrote: post #44
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.

Proper Django Rest Framework should basically have zero view code. Treat Serializers as forms, point at them in the appropriate generic view (or viewset) subclass, and you are done. If you are writing view code in DRF, you are probably doing it wrong.

I don’t think this is fair - the DRF views are a great starting point for a project but I don’t think I’ve ever worked on one where they’re totally sufficient without at least some modification in places if you don’t want to make use of signals (which are very difficult to debug!).

Even things as simple as adding logging to calls on certain end points will require you do provide your own view method (which might then call the mixin’s provided method).

Re: Django 4.1

#105

Post by Spivak »

roflyear wrote: post #92
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. Async in Python is... eh. Rarely is it useful. Sometimes it is, though! Use it when it is useful...

Twisted is a pretty dope though. Wouldn’t migrate a non-async app to async but would absolutely look at async-by-default for new projects.

Re: Django 4.1

#106

Post by traverseda »

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…

> unless 100% of the the libs you want support it you will get stuck on some sync library.

What do you mean by this? Do you mean like an actual deadlock, or just waiting on some kind of IO? Are you trying to use async for performance?

Re: Django 4.1

#107

Post by chpmrc »

fernandotakai wrote: post #76
chpmrc wrote: post #29

Earlier quoted context omitted.

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.

This 1000x. It's such a slippery slope that you'd think by now most people would be aware but no, there's always the "who needs an ORM" guy :)

Re: Django 4.1

#108

Post by chpmrc »

BozeWolf wrote: post #37
chpmrc wrote: post #30

Earlier quoted context omitted.

Why would you block a process that could use CPU cycles to do something useful just to wait on I/O? With the right primitives async is not "hard" nor inconvenient. Maybe you're referring to concurrency?

No I am referring to async, really. Accidentally blocking operations like open() or psycopg or mongodb or some included library which (accidentally) uses any of that stuff. Basically any library requiring requests is not usable. Or worse: open(). It can be hard to determine if something is doing something blocking and if it is, it is hard to debug. Especially in python world which, unlike javascript, was not async fr…

I don't understand, are you saying async is hard or that a poor implementation is a source of issues (e.g. async function that calls sync primitives)? Because I totally agree with the latter but I have no idea what "hard" means. Very little changes in terms of syntax (assuming support for async/await ops) or reasoning.

Re: Django 4.1

#109

Post by omarhaneef »

nickjj wrote: post #85
omarhaneef wrote: post #53

Earlier quoted context omitted.

I was going to say you should offer a tutorial around how this can be used. It is much more useful to have a walk through when people put out such products. And then I decided not to say that because it is up to you how to spend your time and why should you make a tutorial for people if you don't want to. And then I realized, you have actually made dozens and this is the work you do. I think I took a Flask-docker cou…

Thanks a lot! By the way the version of the course on Udemy doesn't get updated. The full version of the course is at https://buildasaasappwithflask.com/ which includes lifetime free updates (it has over 10+ hours of extra updates and new features not on the Udemy version). Udemy is a really bad platform for instructors which is why I've been trying hard to decouple myself from them over time. As for a tutorial on us…

I have not tried it, but I believe I could download it and set up the app based on the readme.

I would not be confident using it, but I'll give it a try.

Re: Django 4.1

#110

Post by acdha »

collinmanderson wrote: post #89
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…

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

> Sometimes developer time is more important than the performance wins of async.

Also, a fair fraction of applications don't see a meaningful benefit compared to other things the developers could be spending time on. Async is not only harder to write in many cases but can force you to deal with new problems which might be harder to manage (e.g. if you use non-trivial amounts of memory, bounding your peak usage can be a challenge).

I've used async a fair amount and it's worked really well in network-heavy uses (HTTPX is really great) but outside of those the savings have been a lot less than people thought, independent of the language used (I'm thinking of a colleague who spent a lot of time trying to beat classic Python with Go and ended up with about a 10% win after a month or so of work because the problem had enough CPU/memory contention to prevent greater savings — that's not a trivial win but it definitely wouldn't have been enough to justify changing languages on its own).

Post reply on HN