Some more things about Django I've been enjoying

Post by acdha » Mon, Jul 27, 2026, 2:55 PM UTC

seanwilson wrote: post #82

acdha wrote: post #79

Earlier quoted context omitted.

> It's like hiding the kitchen knives because they might be misused. I used to agree with this more strongly but over time decided the Django model was actually more effective as your cue to ask whether you should have been writing a Python function instead and calling it (which has been super easy since something like 1.4 or so IIRC). Unless you have a small, very diligent development team it always seemed to end up…

> over time decided the Django model was actually more effective as your cue to ask whether you should have been writing a Python function instead and calling it I get the motivation, but is disallowing brackets and proper variables really the right way to do this? These make code clearer to read and reduce duplication more than they introduce complexity so this is going too far in my opinion and feels arbitrary.

Post by dnautics » Mon, Jul 27, 2026, 4:56 PM UTC

selcuka wrote: post #92

dnautics wrote: post #87

automatic migrations terrifies me. i use elixir/ecto. just write a migration! besides, some times you might want more than one schema for a db table (e.g. one with minimal information, for menus, dropdowns etc, and one with full information for your full CRUD operations)

> some times you might want more than one schema for a db table Django has the concept of "proxy models" where you can define a trimmed down model for the same database table.

Post by selfhoster1312 » Tue, Jul 28, 2026, 8:07 AM UTC

leetrout wrote: post #111

selfhoster1312 wrote: post #44

Earlier quoted context omitted.

It's a practical alternative, but definitely not a drop-in replacement! I've been working on migrating a django project to jinja2 lately, see the diff: https://framagit.org/la-chariotte/la-chariotte/-/merge_reque... A few notables differences: - many controls are now functions/variables (that's good!), and some change name, for example `{% csrf_token %}` -> `{{ csrf_input }}` - calling methods without parenthesis doe…

Yea, I was unclear. That's what I meant by "you can't mix them"... just meant using jinja2 is drop it for the backend. I believe you just set the dirs property in the backend config to look in whatever directory / directories you want it just defaults to jinja2 as you discovered.

Post by [deleted] » Tue, Jul 28, 2026, 9:56 AM UTC

acdha wrote: post #112

seanwilson wrote: post #82

Earlier quoted context omitted.

> over time decided the Django model was actually more effective as your cue to ask whether you should have been writing a Python function instead and calling it I get the motivation, but is disallowing brackets and proper variables really the right way to do this? These make code clearer to read and reduce duplication more than they introduce complexity so this is going too far in my opinion and feels arbitrary.

Oh, believe me, I’ve been on both sides there. My observation was that over time the burden of maintenance and on-boarding new developers pushed me from wanting more flexibility to saying that the restriction was more valuable than I thought.

Post by zbentley » Wed, Jul 29, 2026, 9:49 PM UTC

ltbarcly3 wrote: post #85

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…

async python is always slower than just naively using threads. I don't think there is any application in production anywhere that would not prove me right on this. the complete lack of any kind of scheduling is a disaster. unless you know exactly what I mean by a scheduler please don't reply to this.