Installation

pip install django-fastresolve

and add 'django_fastresolve' to INSTALLED_APPS. That’s it.

You can also call django_fastresolve.install() and django_fastresolve.uninstall() yourself.

How much faster?

On a real project with three urlconfs, timing resolve() on every route, with DEBUG = False:

The more patterns share a level, the bigger the win. Patterns that stock Django already finds in the first couple of tries get about 1 µs slower, from the index lookup.

When does it fall back?

A pattern whose prefix can’t be determined safely gets the empty prefix, which means it is tried for every path, exactly where stock Django would try it. That is the case for:

• lazily translated routes (path(gettext_lazy('about/'), ...))

• regexes that aren’t anchored with ^, or that contain |

• i18n_patterns (LocalePrefixPattern)

• URLPattern/URLResolver subclasses that override resolve()

• pattern classes it doesn’t know

Only the leading literal part of a regex counts: r'^ab?c/' has the prefix 'a'.

Differences from stock Django

tried (on Resolver404 and on ResolverMatch.tried) only lists the patterns that were actually tried, not every pattern before the match.

With DEBUG = True a 404 is resolved again the stock way, so the 404 debug page lists every pattern as usual. That also acts as a self check: if stock Django finds a match where django-fastresolve didn’t, you get an AssertionError saying so, instead of a wrong 404. Please report it if that happens.

The index for a resolver is built on first use. If you append to or remove from urlpatterns afterwards the index is rebuilt; replacing an item in place is not noticed.

To resolve the stock way for a block of code, in the current context only:

from django_fastresolve import stock_resolving

with stock_resolving():
    match = resolve('/some/path/')

Running the tests

uv run pytest

The tests resolve a urlconf full of edge cases, plus a few thousand fuzzed paths, both ways, and assert identical results.