# Django: django-upgrade 1.32.0 out now, with 44 AI-assisted bug fixes > Source: > Published: 2026-08-17 23:00:00+00:00 # Django: django-upgrade 1.32.0 out now, with 44 AI-assisted bug fixes [django-upgrade](https://github.com/adamchainz/django-upgrade) is my tool for automatically upgrading your project code for new Django versions. It rewrites your Python files to fix deprecations and adopt some new features, taking a chunk of the monotony out of upgrading between Django versions. Yesterday, I released [version 1.32.0](https://django-upgrade.readthedocs.io/en/latest/changelog.html), which fixes 44 bugs. Some are big, some are small, and all of them were found by Claude Fable, with this simple prompt: Find and fix bugs Yup, that’s it. Across two rounds of self-directed bug discovery, Claude found and fixed these bugs, matching the coding style and changelog entries. It needed one more prompt to split the fixes into individual commits. I am pretty astounded at how well this little project worked. Claude worked “in the cloud”, while I was doing other stuff, so the bottlenecks to progress were my review capacity and CI runs on GitHub Actions for each commit. My big takeaway is that given such LLM power, the bar for software quality should be raised. Let’s review some of the bugs that it fixed, within the individual code fixers in django-upgrade. ## Bad `url()` to `path()` conversions The `django_urls` fixer converts old `url()` calls, with their regular expression patterns, into [`path()`](https://docs.djangoproject.com/en/stable/ref/urls/#path) calls with the newer route syntax, where possible. Claude found two cases where the “where possible” condition was too optimistic. First, literal angle brackets. In a regular expression, `<` and `>` are literal characters, but in `path()` route syntax they declare parameters. The fixer copied them through unchanged: ``` - url(r"^go//$", views.redirect_angle), + path("go//", views.redirect_angle), ``` The old pattern matched only the exact URL `/go//`, angle brackets included. The new route matches `/go/anything/` and passes `page` as a keyword argument to the view, which likely isn’t expecting it. And if the bracketed text isn’t a valid Python identifier, like ``, Django instead raises `ImproperlyConfigured` at startup. [PR #715](https://github.com/adamchainz/django-upgrade/pull/715) made the fixer skip such patterns. Second, unescaped dots. In a regular expression, a bare `.` matches any character, whilst `\.` matches only a literal dot. The fixer treated both the same, converting: ``` - url(r"^report.pdf$", views.report), + path("report.pdf", views.report), ``` The old pattern also matched URLs like `/reportxpdf`, so the conversion silently narrowed which URLs the pattern matches. Most such patterns contain a “latent bug” where the author meant `\.`, but it’s not django-upgrade’s place to change behaviour. [PR #710](https://github.com/adamchainz/django-upgrade/pull/710) made the fixer leave patterns with unescaped dots alone. These two bug fixes have hopefully closed a loop for me on a client project. Last year, I tried applying django-upgrade to a large client project, and it failed some tests. In my investigation, I cut down the fixers being applied to a short list, including `django_urls`, and still some tests failed. I reached the suspicion that some URLs were being converted incorrectly, but I ran out of time to properly investigate. Now a bot has found and fixed these bugs without me even trying, I’ll be trying that upgrade again! ## Escaping backwards Django 3.0 deprecated `django.utils.text.unescape_entities()` in favour of Python’s [`html.unescape()`](https://docs.python.org/3/library/html.html#html.unescape). Back in version 1.2.0 (2021), I added the `unescape_entities` fixer to django-upgrade to rewrite calls to the new function. But I accidentally made it rewrite calls to the inverse function, `html.escape()` instead of `html.unescape()`: ``` python -from django.utils.text import unescape_entities +import html -text = unescape_entities(raw) +text = html.escape(raw) ``` Woops! You can see how the results would vary: ``` >>> html.unescape("Tom & Jerry") 'Tom & Jerry' >>> html.escape("Tom & Jerry") 'Tom &amp; Jerry' ``` 😬 [PR #684](https://github.com/adamchainz/django-upgrade/pull/684) was the bug fix to correctly rewrite code to use `html.unescape()`. This fixer survived nearly five years of use, perhaps through a combination of few projects activating it, no one noticing when it broke their code, and users potentially working around the issue by disabling the fixer. I’m glad Claude could spot the obvious error. ## `TestCase.multi_db = False` fixer blocking all database queries Django 2.2 replaced the test case attributes `allow_database_queries` and `multi_db` with [`databases`](https://docs.djangoproject.com/en/stable/topics/testing/tools/#django.test.SimpleTestCase.databases). django-upgrade rewrites those old attributes to the new one, but it mapped `multi_db = False` to an empty list: ``` class OrderTests(TestCase): - multi_db = False + databases = [] ``` That looks sensible at first glance, but it’s wrong. Under Django’s deprecation shim, `multi_db = False` still allowed queries against the default database. The rewritten `databases = []` blocks queries against *all* databases, breaking previously-working tests with `DatabaseOperationForbidden` errors. [PR #727](https://github.com/adamchainz/django-upgrade/pull/727) corrected the mapping: ``` class OrderTests(TestCase): - multi_db = False + databases = ["default"] ``` This is another bug I introduced in version 1.2.0. I guess no one hit this code path, since it would trigger an obvious test case breakage. But with open source, it is hard to know how many folks will actually make a bug report. ## Bar height++ These bug fixes are a subset of the 44 in the release—see the [changelog](https://django-upgrade.readthedocs.io/en/latest/changelog.html) for the full list. There are definitely some more bugs lurking, but for now I’m out of time and energy for django-upgrade. I even left some harder-to-review bug fixes in draft PRs for my next pass at the project. But yeah, since bugs like these are now fairly cheap to find, I hope that the software quality bar goes up. Applying fixes still requires some vigilance in review and checks from deterministic tools like linters, but good projects generally already apply such tools. And while it can be hard to trust LLMs to build features, where they often generate large piles of code, this genre of small, targeted bug fixes are an easy win. Try my prompt on your own project. Here it is again: Find and fix bugs Read my book [Boost Your Django DX](https://adamchainz.gumroad.com/l/byddx), freshly updated in November 2024. One summary email a week, no spam, I pinky promise. **Related posts:** - [Introducing django-upgrade, a tool for upgrading your Django projects](https://adamj.eu/tech/2021/09/16/introducing-django-upgrade/) - [django-upgrade Mega Release 1.11.0](https://adamj.eu/tech/2022/10/26/django-upgrade-mega-release/) - [django-upgrade release with Django 4.2 fixers](https://adamj.eu/tech/2023/02/17/django-upgrade-release-django-4.2/) **Tags:** [django](https://adamj.eu/tech/tag/django/)