(All tags.)
Last month, I held another quiz at the December edition of Django London. The December quiz is an annual tradition at our meetup, a way of making this final event of the year more relaxed and giving away some nice prizes. This was the seventh quiz that I’ve presented, and the eighth overall.
Previously, we covered bearer authentication within HTTP’s general authentication framework. In this post, we’ll implement basic authentication, where the client provides a username and password.
Django 6.0 was released today, starting another release cycle for the loved and long-lived Python web framework (now 20 years old!). It comes with a mosaic of new features, contributed to by many, some of which I am happy to have helped with. Below is my pick of highlights from the release notes.
HTTP has a general authentication framework that defines a pattern into which various authentication schemes can fit. Clients may provide an authorization request header that contains a credential. If authorization is missing or invalid, the server may respond with a 401 (Unauthorized) status code, including a www-authenticate header advertising what authentication schemes are supported. Otherwise, the server can respond with the authenticated resource.
Here are some Django-related deals for this year’s Black Friday (28th November) and Cyber Monday (1st December), including my own.
HTTP supports response compression, which can significantly reduce the size of responses, thereby decreasing bandwidth usage and load times for users. It’s a cheap and valuable technique for improving website performance.
runserver autoreloadingDjango’s runserver automatically reloads when you change Python files. Without this autoreloading feature, you’d need to manually restart the server every time you made a code change.
Here’s a little tip based on some recent work. The project has a URL pattern where the first part of the URL matches the current role the user is viewing the site as. Let’s say the roles are “chef”, “gourmand”, and “foodie”—example URLs might look like this:
ModelAdmin.get_queryset() by viewWithin Django’s popular admin site, you can override ModelAdmin.get_queryset() to customize the queryset used by the admin views. It’s often used for performance optimizations, such as adding a select_related() call to batch-fetch related objects:
I’ve found it useful, on occasion, to iterate through all registered URL patterns in a Django project. Sometimes this has been for checking URL layouts or auditing which views are registered.
From Django 5.2 (April 2025), the runserver management command outputs a warning:
I recently released a new package called inline-snapshot-django. It’s a tool for snapshot testing SQL queries in Django projects, described shortly.
Python comes with two built-in profilers for measuring the performance of your code: cProfile and profile. They have the same API, but cProfile is a C extension, while profile is implemented in Python. You nearly always want to use cProfile, as it’s faster and doesn’t skew measurements as much.
Adam Hill posted a question on Mastodon: he wants a model field that uses choices that doesn’t generate a database migration when the choices change. This post presents my answer. First, we’ll recap Django’s default behaviour with choice fields, a solution with callable choices, and the drawbacks.
Django 5.2 was released last Wednesday, another exciting step forward for our favourite web framework. It comes with a composite of new features, contributed to by many, some of which I am happy to have helped with. Below is my pick of highlights from the release notes.
JavaScript’s import statement lets module scripts import objects from other scripts. For example, you can define a script as a module in HTML:
You might see this message when running pytest on your Django project:
{% url '' %}Previously, I covered using 1/0 to crash Python within minimal typing, useful to quickly answer questions like “does the code even get here?”. Recently, I wanted to do the same in Django templates, to trace if a given template was even being rendered, and under which code paths.
Yesterday, I held another quiz at the December edition of Django London. The quiz is a regular tradition at our meetup, a way of having a more relaxed event in December and giving away some nice prizes. This was the sixth quiz that I’ve presented, and the seventh overall.
Here’s another technique for using pdb within Django. I will add this to the new debugging chapter of Boost Your Django DX in a future update.
{% breakpoint %} tagIn my recent Boost Your Django DX update, I added a new chapter on debuggers. Here’s an extra technique I didn’t finish in time for the update, but I will include it in the next one.
breakpoint()Python’s breakpoint() function opens its debugger, pdb, which pauses the program and allows you to inspect and modify things. Let’s look at an example of using it within a Django view, from a sample project included in Boost Your Django DX.
Heavy refactoring of models can leave a Django project with “ghost tables”, which were created for a model that was removed without any trace in the migration history. Thankfully, by using some Django internals, you can find such tables.
Here are some Django-related deals for this year’s Black Friday (29th November) and Cyber Monday (1st December), including my own.
I have just released the second update to Boost Your Django DX, my book of developer experience (DX) recommendations for Django projects. This update contains a new chapter, changes some recommended tools, and upgrades to Python 3.13 and Django 5.1. Overall, the book is 45 pages longer, now totalling 326!