I would like to reopen ticket 30515, but according to this. I shouldn’t.
However, I would like to reopen the discussion, to perhaps redecide on closing the ticket as wontfix.
There seems to be some indications that there are use cases where django.shortcuts.redirect is impractical and django.shortcuts.resolve_url is the right tool to use.
For my own part, I am implementing SSO login on multiple products where I work, and for this resolve_url has proven the right tool. That is after I discovered it, after I had already implemented something similar myself.
Using resolve_url has made my code simpler, by making it much easier to get the actual URL behind settings like e.g. LOGIN_REDIRECT_URL, and LOGIN_URL, that may be a path or a name, depending on how the project is setup. In some of my code I have to process resolved URLs, and may not even redirect to it. Also in testing, resolve_url has proven useful to e.g. verify that redirection headers are set to the correct value.
Now review is dragging along long enough that I can write this post, and all because resolve_url is not documented along with the other shortcuts.
Thank you @beruic for following the documented procedure to create a topic for further discussion.
I think revisiting this makes sense today, given the evidence of extended real-world usage and the emergence of newer use cases since the original decision.
First, the argument that documenting redirect() is sufficient no longer feels adequate. In Django, lack of documentation is generally taken to imply a private or internal API. resolve_url() lives in django.shortcuts, has been stable for years, and is used directly by widely adopted third-party projects. Treating it as effectively private while it is de facto public creates ambiguity for users.
Second, redirect() is not a substitute in all cases. It performs additional work and returns an HTTP response, while there are legitimate scenarios where callers need the resolved URL itself. Examples were given in the tickets (original and dupes), including preprocessing URLs, non-HTTP redirect responses, SSO flows, and testing, where asserting on the resolved target is useful without performing a redirect.
Overall, this is about acknowledging how the function is already used in practice and making Django’s primitives clearer and more explicit for users.
I’ve used this in production applications as well. Given @adamchainz’s findings of thousands of usages across other projects, and since it’s stable, it seems like a good idea to formalize it through documentation.