Live data from Hacker News

Django: what’s new in 6.0

adamj.eu

121–127 of 127 posts

Re: Django: what’s new in 6.0

#121
post #108

Earlier quoted context omitted.

Although we could say the same thing about Kafka, couldn't we? It's made for much higher throughput and has usually other use cases, but it's also great until it's not great.

At least the last time I used Kafka (which was several years ago so things might have changed) it wasn't at all easy to get started. It was a downright asshole in fact. If you pursue a relationship with an asshole, you shouldn't be surprised when they become cold to you

Yes, absolutely. It's still pretty much that way. Especially if you want to make changes to a running installation, add nodes etc.

Re: Django: what’s new in 6.0

#122
post #118

Earlier quoted context omitted.

Any docs? Django migration is a HUUGE pain point for us.

manage.py makemigrations myapp --empty --name add_some_view (in the migration file) operations=[migrations.RunSQL("Create View some_view AS ....", "DROP VIEW IF EXISTS...."] (in your models.py) class SomeView(models.Model): class Meta: db_table = 'some_view' managed = False manage.py makemigrations myapp --name add_some_view_model

An extremely common thing to do. Also great with materialized views. I bet it's documented somewhere in Django's docs.

Re: Django: what’s new in 6.0

#123
post #79
post #69

Earlier quoted context omitted.

Correct. Django 6.0 comes with a standardised API, with 2 testing backends (ImmediateBackend and DummyBackend). You need a third-party backend to store and execute tasks.

Good to know. So no need for Django Q2 or Celery anymore either. I guess unless one has a specific reason. Has there been discussion about adopting/embedding django-tasks into Django 6.x?

django-tasks is the reference implementation for django.tasks, by the same author. It's up for discussion if and when the DatabaseBackend gets merged, and it seems likely to me that a Redis-based backend would be suggested at some point. It takes time and energy though!

Re: Django: what’s new in 6.0

#124
post #75
post #58

Given that Python tends to produce fewer hallucinations when generated by LLMs I wonder if former Django developers using AI tools are secretly having a blast right now.

What a lot of people don’t know is that SWE-bench is over 50% Django code, so all of the top labs hyper optimize to perform well on it.

I know python is more prevalent in SWE-Bench than any other language, but more than 50% django sounds like a big stretch. Citation?

Edit, it's about 37%, and python-only. https://arxiv.org/pdf/2310.06770v3

Re: Django: what’s new in 6.0

#125
post #109
post #56

Earlier quoted context omitted.

Wouldn’t Jinja2 macros count?

I stayed away from Jinja2 ... was under the impression it has lower performance. But I could have been wrong all these years.

>For nearly all cases, Django’s built-in template language is perfectly adequate. However, if the bottlenecks in your Django project seem to lie in the template system and you have exhausted other opportunities to remedy this, a third-party alternative may be the answer.

>Jinja2 can offer performance improvements, particularly when it comes to speed.

https://docs.djangoproject.com/en/6.0/topics/performance/#al...

Re: Django: what’s new in 6.0

#126

Earlier quoted context omitted.

React allows for encapsulation of state in a reusable component, its more than just templating.

React also requires you to know the long list of do's and dont's and is littered with minefields that most average developers are not even aware of. Everyone just busts out "React" for every small thing, but few commit to actually learning this pretty complicated technology. The last two recent Cloudflare outages were because of React.

Really?

Re: Django: what’s new in 6.0

#127
post #72

Earlier quoted context omitted.

There are a lot of cool things about these, one that they are less typo prone and also they are often much faster. The downside is I find them hard to read. I think the template approach isn't quite right and yet neither is the functional approach. At the end of the day these are a type of tree structure; I think we could conjure a new mechanism that gets the best of most/both worlds.

Yeah, I agree, I find them hard to read. JSX is the best thing I've used. Elsewhere in the thread someone mentioned Cotton which seems to strike a different balance. To be honest my main problem with templates is they have to be one per file. In principle there's no difference between naming a new file and naming a function, but in practice it just sucks. It's a higher barrier so people are less likely to write small…

As an FYI, I'm with the template strings folks (new feature in 3.14) and we're building an HTML system around the idea of JSX-style components as callables, but with actual strings of HTML. Check our components page for more detail.

With template strings, the symbols in the HTML string a just like Python code. Static analysis tooling can step in and do things.

We have ambitions to start an interoperability movement in Python HTML, so htpy and tdom could agree on a common Node structure.

Post reply on HN