Looking forward to Django 6.0
About the upcoming release of Django 6.0.
It’s been a busy summer. Django 6.0 is taking shape. It’s largely already there.
The feature freeze and alpha version are due September 17th. So I wanted to talk about that today.
Upcoming highlights
Python 3.12+
The minimum Python version for the Django 6.x series will be Python 3.12.
Part of me finds this amazing. How are we on 3.12 already? That’s recent. I know the Django 5.2 LTS has a long way to go, but we can start using the new goodies.
I think Django’s Python support policy is about right, but with Python’s (now not so) new annual release cycle, Python 3.12 is already not really recommended, being in the security phase of its lifecycle.
The official Status of Python Versions has only Python 3.13 coloured green currently. We should already be using that, but I can’t help but think that’s a little unrealistic for the bulk of the user base. Many folks (I’d guess) hang out on an older Python until they’re forced to update. I wouldn’t want us to push people too hard here.
But I’m excited about the new toys 🧸
CSP in core
The headline feature has to be Content Security Policy (CSP) support in core.
From the docs:
Content Security Policy (CSP) is a web security standard that helps prevent content injection attacks by restricting the sources from which content can be loaded. It plays an important role in a comprehensive security strategy.
It’s a defence in depth measure: with correct escaping and so on you’re safe from cross site scripting attacks and so on, but CSP allows you tell the browser Only load scripts from same host as this page itself, for example, which means, if somehow a rogue script tag makes it in somehow, the browser will plain refuse to load a resource from another domain.
CSP is massively complex. It’s a great example of a hard battery that Django should provide. We don’t need to provide every possible utility for every possible use case, especially ones that are trivial for users to provide themselves (and package up if they’re more generally useful) but there’s a category of more difficult problems, that really do need that extra level of polish and care. (Django’s signing utilities are my favourite personal example. I’m really glad those are part of Django itself.)
Django-CSP has been available for years as a third-party package. Having it in core should encourage more sites to take it up, and it brings it under Django’s stability and compatibility guarantees.
This is a big win.
django.tasks
As I write, this is not quite merged, but it should be before the alpha release goes out. The core interface and immediate backend for django.tasks will now be in core. This is the next step for the DEP 14 to add background tasks to Django.
The actual DB backend, which you’ll need to delay tasks, will remain in its separate package for now. The goal is to eventually merge this, but we want to iterate and assure stability before merging it into Django, and tying it to the long release cycle and strict backwards compatibility guarantees.
Django-tasks was already part of Wagtail for coming up for a year now. I’m not particularly worried about it. More excited to see it progressing nicely. We could rush here, but slowly, slowly wins the day.
I’m keen to see if existing queue packages — of which there are numerous, which was the point of the DEP — provide wrappers using the django.tasks API. That would be my hope.
template-partials
The thing I’m most looking forwards to though is django-template-partials being merged into core. I began django-template-partials back on Django 4.2. I introduced it at DjangoCon Europe in Edinburgh. I said at the time that it was something that it was time for us to have in core, whether partials itself, or a something different along the same lines.
The uptake was phenomenal. We had a few rounds of quick initial feedback, and then it’s been largely stable ever since.
This summer I’ve been mentoring Farhan Ali Raza for Google Summer of Code (GSoC) as he’s done an excellent job in getting template-partials ready for core.
If you’ve not yet seen it, you should read the HTMX Essay on Template Fragments. As I sat down to the new project (recently retired as Fellow) I knew this was what I needed. I was using HTMX, and template partials let you select just a small part of a main template to render for an AJAX-style request.
The new docs give a user-details example:
{% partialdef user-info %}
<div id="user-info-">
<h3></h3>
<p></p>
</div>
{% endpartialdef %}
Partials are integrated with the template loader, so if this fragment was defined in authors.html you could access it directly in your view, or a template include using the template name plus a fragment identifier for the partial: "authors.html#user-info".
This ability lets you reuse partials whilst keeping them next to the rest of the template they refer to, maintaining that favourite of ours, Locality of Behaviour.
As always, as your templates get more complex, you can pull your partials out to a separate template (and then swap the new partial tag for an include with no other changes required) but partials allow you to work in place for a lot longer than was previously feasible. If I’m honest, they’ve changed the way I work, and I’d not now be without them.
The docs have a nice example of reusing a partial multiple times:
{% block content %}
<h2>Authors</h2>
{% for user in authors %}
{% partial user-info %}
{% endfor %}
<h2>Editors</h2>
{% for user in editors %}
{% partial user-info %}
{% endfor %}
{% endblock %}
(Buttondown's preview doesn't seem to like this example. If it doesn't render, do click the link to the docs. Update: fixed it with a verbatim tag 👊)
What I like about this is it shows the organisational role of partials. You can render partials inline where they’re defined. Frequently though, the contents of a partial gets quite complex. In these cases, it’s nice to extract it, to the top or bottom of the file, leaving the main template as an easily scannable skeleton. It makes the structure of your templates much more transparent.
I’ve got an Alpine.js forms example where I also show how I use template-partials for customising Django form and form field templates.
Often you want some JS to add behaviour to a form field based on user input. With partials, I can set the field template to a particular partial that lives in the same file as the main form template (which itself can be a partial in the same template as the view, and often is)…
template_name="user_form.html#bio-field"
… and so on.
Where you’ve got multiple fields interacting, and state being held on the form, say, having the form and all its field templates in the same file is massively liberating.
Click through and browse the example.
As I say, I couldn’t be more excited to see template-partials in core. It’s a big YES! 💃
Google Summer of Code
Over the years, Google Summer of Code, GSoC has been a real boon to Django. It’s a lot of work to organise, we get many applications that are low quality, but among them there are always some gems. Jannis (Django’s second all time contributor in terms of number of commits, Anaconda and PSF all star) was a GSoC student. Sage (Django ORM contributor and now on the Wagtail core team and working on Wagtail full-time) was a GSoC student. From when I was a Fellow, the cross-DB JSONField and the in-core Redis cache backend were the standout GSoC-added features, but per-instance field lookups, moving models between apps, and many more I can’t recall were all the result of GSoC projects. It’s worth our effort.
This year, Farhan has done a super job bringing django-template-partials into core. There was just enough complexity for it to be a task that had sat on my back burner for a year or so, and not likely to bubble up. After all, it could happily live in the third-party package forever — no need to merge it. Having the input of a GSoC student gave it the extra energy that was other wise missing.
I think, in general, it’s a good policy to point GSoC projects to ecosystem system packages that either need extra help or that we’re looking to merge to core. That bump up in quality (mostly handling edge-cases) that you need for Django itself is hard. You need dedicated time for that. Hence a GSoC project is perfect.
It seems like each year we struggle slightly to get project ideas and mentors for GSoC. A third-party package project is often well scoped, and having the GSoC student gives the maintainer a bit of a boost to take on some the package backlog. If we can just boost the expectation that putting forward a third-party package project for GSoC is the way to go, we can likely help out across the board at both ends.
Admin Keyboard Shortcuts
So, quickly, whilst we’re on the topic of GSoC, there’s another project done by Rafey Khan this year that you really should check out. The goal is to add keyboard shortcuts to the django-admin. Go check it out: django-admin-keyshortcuts.
The package is a simple pip install, and add to your INSTALLED_APPS and you’re up and running.
Ideally this is eventually part of the Django admin itself, but the third-party packages allows you to get going with it now, find the issues, and give feedback. If you can try it in your work projects. How does it go?
Django on the Med 🏖️
Finally, Paolo and I have been organising three days of development sprints, under the name of Django on the Med 🏖️
We going to aim for twice a year, in Pescara, Italy, and Palafrugell, Spain. Spring and Autumn.
We’ve got a simple site, do go check it out:
There’s lots of info on what we’re trying to achieve, what success looks like, how to get there and all the rest of it.
The first one will be 7th-9th October 2025, in Palafrugell Spain. The response has already been awesome. Hope to see you there!