Django: django-upgrade 1.32.0 out now, with 44 AI-assisted bug fixes

Adam Johnson released django-upgrade 1.32.0, which fixes 44 bugs found and fixed by Claude Fable across two rounds of self-directed bug discovery using the prompt "Find and fix bugs." The fixes include correcting the django_urls fixer's handling of literal angle brackets and unescaped dots in url()-to-path() conversions, and a long-standing error where the unescape_entities fixer rewrote calls to html.escape() instead of html.unescape(). Johnson said the bottlenecks were his review capacity and GitHub Actions CI runs per commit, and concluded the bar for software quality should be raised given such LLM power.

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/<page /$", views.redirect angle , + path "go/<page /", views.redirect angle , The old pattern matched only the exact URL /go/<page / , 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 <not-a-name , 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 &amp; Jerry" 'Tom & Jerry' html.escape "Tom &amp; Jerry" 'Tom &amp;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/