Django: iterate through all registered URL patterns
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.
(All tags.)
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!
Happy DjangoCon US 2024 to you. Whilst I am not there, I have adopted the spirit of the season and got to work hacking together a new tool.
update_last_loginDjango’s test client provides two methods to log in a user: login() and force_login(). The latter one is faster because it bypasses the authentication backend, including password hashing, and just sets a session to have the user logged in. Typically, you’d want to use it in setUp() like this:
Django provides us with a rich set of view decorators. In this post, we’ll look at a technique for hoisting repeated use of these decorators to reduce repetition.
Here’s an example of a common pattern in Django projects:
Recently, I built a Microsoft Teams bot for a client, inside their Django project. It wasn’t fun or easy, but the experience did increase my resiliency as a developer. I also went into this forewarned by my wife, a product manager also known as “the integration queen”, who has experienced the difficulties of the Teams API first-hand.
.all()”Here’s a little ORM pet peeve of mine that may deepen your understanding of how QuerySets work.
Django’s SECRET_KEY setting is used for cryptographic signing in various places, such as for session storage and password reset tokens. This makes keeping it secure a high priority since an attacker with the key could forge things like password reset tokens.
argparse, the standard library module that Django uses for parsing command line options, supports sub-commands. These are pretty neat for providing an expansive API without hundreds of individual commands. Here’s an example of using sub-commands in a Django management command:
Django requires every change to model fields and meta classes to be reflected in database migrations. This applies even to things that don’t typically affect the database, such as Field.choices. When iterating on code, it’s easy to make a model change and forget to update the migrations accordingly. If you don’t have any protection, you might even deploy code that crashes due to out-of-date migrations!