News

Django security releases issued: 6.0.7 and 5.2.16

Three new CEVs have been addressed in the latest security releases. We encourage all users of Django to upgrade as soon as possible.

Django on the Med: Venue and Hotel Details for Edition 2!

A few more confirmed details for Django on the Med 🏖️ 2026, which will take place from September 23 to 25, 2026 in Pescara, Italy 🇮🇹.

Thank you Lacey - Django Commons

Django Commons credits Lacey Henschel for helping shape the admin team from day one, including onboarding Django REST Framework, building the recruitment pipeline, and creating project check-ins that prevent stagnation. Her decision to step down is framed as proof that sustainability includes taking breaks without guilt, with hard judgment calls rooted in respecting maintainers and community trust.

---

Django Software Foundation

Last Call 2026 Django Developer Survey

The 2026 survey is ending next week on July 13th. Thank you to everyone who already filled it out. Please encourage all your friends and colleagues to do the same. This is the single most important tool for collecting data from the Django community and directly influences the work of Fellows and new features.

---

Updates to Django

Today, "Updates to Django" is presented by Raffaella from Djangonaut Space! 🚀

Last week we had 6 pull requests merged into Django by 5 different contributors

Some interesting post from the Django Forum:

• Feedback wanted: pluggable migration recorder (MIGRATION_RECORDER setting)
• PostgreSQL: compile __in lookup to "= ANY(%s)" to avoid O(N) placeholder rewrite
• Implementing a Formal Experimental API for Django

---

Sponsored Link

Level up with mentorship

You can have a great manager and still want an outside perspective. I explain why in my FAQ.

---

Articles

The Missing Link: Thinking in Use Cases with Django Query Selectors

Where your queries should live - and how selectors keep your business logic lean and readable.

The Missing Link: Thinking in Use Cases with Django Query Selectors

Atomic, chainable queryset methods answer how you fetch; selectors answer what you are fetching for. Move each read use case into a named, testable function that composes CQS methods, so views and services stay thin and business logic stops spreading across views and forms.

Nifty Django Feature: resolve function

Django's resolve() turns a request path into a ResolverMatch, giving you the target view function, extracted kwargs like pet_id, and the URL name. The same mechanism can be applied to your web server logs to reconstruct which views users hit over time, as long as you track URL changes between deployments.

How to Read Postgres EXPLAIN: A Guide to Scan Types

Scan type in a Postgres EXPLAIN plan tells you whether the database reads the whole table, walks an index, builds a bitmap, or even satisfies the query entirely from an index (index-only scan). This guide walks through sequential, index, bitmap heap, parallel variants, and index-only scans so you can spot why a query is slow and what the planner is optimizing for.

Why we built yet another Postgres connection pooler

Connection poolers often break session state, forcing apps to stop relying on SET and sidelining LISTEN/NOTIFY semantics. PgDog adds a SQL-aware layer that tracks SET variables per client and proxies LISTEN/NOTIFY across processes while preserving transactional behavior, so scaling doesn't mean rewriting core Postgres usage.

A small proposal to form rendering in Django

A code example around this new feature idea, which is an extension to Django's form rendering capabilities to include widgets templates inside a form renderer.

Fixing the dictionary with Python 3.14

A Hugo van Kemenade look at "And now for something completely different" in the Python 3.14 cycle starts with the π symbol and an Oxford English Dictionary markup mistake. The reported rendering bug was fixed within about a year, highlighting how even reference sites can need careful dictionary-grade scrutiny.

How to publish to PyPI using GitHub Actions securely

GitHub Actions incidents have pushed many teams to tighten publishing workflows, and this guide lays out three practical steps for PyPI publishing: run zizmor, remove overly broad GITHUB_TOKEN permissions and persisted checkout credentials, and pin actions to commit SHAs. It also recommends using PyPI Trusted Publishing with a GitHub environment that requires an approval gate before releases.

---

Videos

Updates on Django's Async Story - Talk Python Live Stream

Carlton Gibson joined host Michael Kennedy to provide an in-depth look at Django's ongoing async story, where it stands now, and what to expect in future releases.

---

Django Fellow Reports

Jacob Walls

Jacob is on vacation this week.

Natalia Bidart

Intense week! ✨ I was mostly covering solo this week ⛑️, so it was a mix of keeping everything moving and diving deep where needed. A big chunk of time went into tracking down and fixing a docs build regression for the website (thanks Carlton for spotting it and Tobias for the help debugging), which uncovered a subtle mismatch between how Django (core) builds docs and how the website consumes them. Alongside that, I spent time on a few deeper investigations that had been lingering (snoozed over and over in my inbox ⏰), finally unblocking design questions and follow-ups that needed proper attention. On the security side 🔐, I handled prenotifications and a wave of incoming reports, closing out a number of invalid ones and keeping things tidy.

Overall, a very hands-on week 🧰 balancing throughput with some worthwhile deep dives that should pay off going forward ⚖️.

---

Projects

otto-torino/django-baton

A cool, modern and responsive django admin application based on bootstrap 5 that brings AI to the Django admin.

unfoldadmin/django-unfold

A modern Django Admin approach.

10 Jul 2026 3:00pm GMT

09 Jul 2026 4:00am GMT

It's been a while since my last post, mainly because June saw me start a new client, GSOC really taking off and we have our first real customers in Hamilton Rock with money being deposited and some money being spent, not without its teething issues! Also with a fair amount of social engagements as well!

But anyway, on to today's post. During June I proposed a new feature idea which is an extension to Django's form rendering capabilities to include widgets templates inside a form renderer. Currently, it's only possible to Override widgets at a project level by specifying the template name, or you have to overwrite the widget and then specify your own custom template name and then use that custom widget. It's not possible to customize widgets at the form renderer level.

My idea is to extend the form renderer API. Well actually extends the budget rendering API to check the specified form renderer. It should only be an extension to a private method inside the widget API. Below is the relevant code that I actually got Claude to spit out inside Hamilton Rock today. This is a first iteration which very likely needs some improvement, but it does work!

_CAMEL_BOUNDARY = re.compile(r"(?<!^)(?=[A-Z])")

class Widget(metaclass=MediaDefiningClass):
    ...
    
    def _render(self, template_name, context, renderer=None):
        if renderer is None:
            renderer = get_default_renderer()
        # Walk the widget MRO for a ``<widget>_template_name`` on the renderer.
        # A class that defines its own ``template_name`` short-circuits (attribute
        # shadowing): a custom widget keeps its template over a base override,
        # while an unstyled subclass resolves up to a styled base.
        for klass in type(self).__mro__:
            slug = _CAMEL_BOUNDARY.sub("_", klass.__name__).lower()
            override = getattr(renderer, f"{slug}_template_name", None)
            if override is not None:
                template_name = override
                break
            if "template_name" in klass.__dict__:
                break
        # Same trust posture as Django's own Widget._render.
        return mark_safe(renderer.render(template_name, context))  # noqa: S308

and here is the current method from the source

    def _render(self, template_name, context, renderer=None):
        if renderer is None:
            renderer = get_default_renderer()
        return mark_safe(renderer.render(template_name, context))

There is also some code to allow admin classes to specify a renderer so that your custom renderer doesn't overwrite admin form widgets. In the coming week or so, I will extract this code into a third-party package for others to use.

But what's the real win with this potential change? Honestly I see this unlocking simple packages which unlock custom and complete form rendering packages with Django. Most of these themes would be HTML, CSS & Javascript, with the only python being the declaration of the FormRenderer class like so (pulled from Hamilton Rock):

class DrawerFormRenderer(TemplatesSetting):
    form_template_name = "forms/drawer_form.html#form"
    field_template_name = "forms/drawer_form.html#field"

    text_input_template_name = "forms/drawer_form.html#text_input"
    email_input_template_name = "forms/drawer_form.html#text_input"
    password_input_template_name = "forms/drawer_form.html#text_input"
    date_input_template_name = "forms/drawer_form.html#text_input"
    number_input_template_name = "forms/drawer_form.html#number_input"
    select_template_name = "forms/drawer_form.html#select"
    textarea_template_name = "forms/drawer_form.html#textarea"
    checkbox_input_template_name = "forms/drawer_form.html#checkbox"
    radio_select_template_name = "forms/drawer_form.html#radio"

If you like the look of this, give the feature a thumbs up on the issue and we can hopefully get it progressed. Also do let me know what glaring holes that I have missed in this idea.

08 Jul 2026 5:00am GMT