Some more things about Django I've been enjoying

Post by ptx » Mon, Jul 27, 2026, 9:36 AM UTC

miki123211 wrote: post #71

hecreto wrote: post #57

Not to be a downer since a lot of JEvans’ content is great. People should really give .NET a try. I don’t know if we are just old greybeard curmudgeons who look at this and go “is this a new thing? haven’t we been doing this for decades?”, but .NET out of the box with a few packages for databases, logging, etc is so pleasant you don’t even think about it. Maybe it’s just not a vocal community idk.

agreed 100%, the most under-appreciated programming ecosystem of them all. It's also the only one that has support for making truly native apps for all four major platforms: Windows, Linux, MacOS and iOS. If you're willing to put in the work and make separate, native UIs for each, C# is the only way to go. It's a rich enough language that it binds reasonably well to both Java (on Android) and Objective C / Swift (on…

Post by ptx » Mon, Jul 27, 2026, 9:44 AM UTC

mmclar wrote: post #74

echoangle wrote: post #23

Earlier quoted context omitted.

> I can't quite picture how operator overloading would look like, could you give an example? Instead of this: self.filter(end__gt=self._midnight(today)) You could write a "Field" class that implements __getattr__ and __gt__ so you could do self.filter(Field.end > self._midnight(today)) The "Field.end > self._midnight(today)" would evaluate to an object that would just store "my field name is end and my value needs to…

SQLalchemy does that. One advantage of the Django syntax is that it can be (pretty much) directly dropped into a query string on any admin page or DRF query and filter the results. E.g. the admin page for all the events after noon today: admin/event/?end__gt=2026-07-26T12:00:00 Being able to do ad-hoc queries using the same paradigm your app queries are written in, and then pass urls around with those queries include…

Post by melodyogonna » Mon, Jul 27, 2026, 9:56 AM UTC

Post by CraigJPerry » Mon, Jul 27, 2026, 10:47 AM UTC

physicsguy wrote: post #97

CraigJPerry wrote: post #18

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

I think people in the Python world just don't yet have a good mental model of async either. I recently have had conversations with a number of people who have switched to FastAPI because "it's faster" even when they're using it to serve ML models which are compute bound and there's nothing you can await on.

Post by Oxodao » Mon, Jul 27, 2026, 11:39 AM UTC

jorl17 wrote: post #86

CraigJPerry wrote: post #18

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

Everytime I have to deal with websockets in Django, I want to rip my eyeballs out. Most of the time what I really want is just push support, and don't need bidirectional communication, i.e. SSE. But it's the same thing: both are a pain to work with in Django. I find django-channels so cumbersome. So, for my latest projects, I've ended up offloading this push functionality to a service like Centrifugo. Django talks to…