django.urls utility functionsLink to this heading#reverse()Link to this heading#The reverse() function can be used to return an absolute path reference\nfor a given view and optional parameters, similar to the url tag:
viewname can be a URL pattern name or the\ncallable view object used in the URLconf. For example, given the following\nurl:
from news import views\n\npath("archive/", views.archive, name="news-archive")\nyou can use any of the following to reverse the URL:
\n# using the named URL\nreverse("news-archive")\n\n# passing a callable object\n# (This is discouraged because you can't reverse namespaced views this way.)\nfrom news import views\n\nreverse(views.archive)\nIf the URL accepts arguments, you may pass them in args. For example:
from django.urls import reverse\n\n\ndef myview(request):\n return HttpResponseRedirect(reverse("arch-summary", args=[1945]))\nYou can also pass kwargs instead of args. For example:
>>> reverse("admin:app_list", kwargs={"app_label": "auth"})\n'/admin/auth/'\nargs and kwargs cannot be passed to reverse() at the same time.
If no match can be made, reverse() raises a\nNoReverseMatch exception.
The reverse() function can reverse a large variety of regular expression\npatterns for URLs, but not every possible one. The main restriction at the\nmoment is that the pattern cannot contain alternative choices using the\nvertical bar ("|") character. You can quite happily use such patterns for\nmatching against incoming URLs and sending them off to views, but you cannot\nreverse such patterns.
The current_app argument allows you to provide a hint to the resolver\nindicating the application to which the currently executing view belongs. This\ncurrent_app argument is used as a hint to resolve application namespaces\ninto URLs on specific application instances, according to the namespaced\nURL resolution strategy.
The urlconf argument is the URLconf module containing the URL patterns to\nuse for reversing. By default, the root URLconf for the current thread is used.
The query keyword argument specifies parameters to be added to the returned\nURL. It can accept an instance of QueryDict (such as\nrequest.GET) or any value compatible with urllib.parse.urlencode().\nThe encoded query string is appended to the resolved URL, prefixed by a ?.
The fragment keyword argument specifies a fragment identifier to be\nappended to the returned URL (that is, after the path and query string,\npreceded by a #).
For example:
\n>>> from django.urls import reverse\n>>> reverse("admin:index", query={"q": "biscuits", "page": 2}, fragment="results")\n'/admin/?q=biscuits&page=2#results'\n>>> reverse("admin:index", query=[("color", "blue"), ("color", 1), ("none", None)])\n'/admin/?color=blue&color=1&none=None'\n>>> reverse("admin:index", query={"has empty spaces": "also has empty spaces!"})\n'/admin/?has+empty+spaces=also+has+empty+spaces%21'\n>>> reverse("admin:index", fragment="no encoding is done")\n'/admin/#no encoding is done'\nreverse_lazy()Link to this heading#A lazily evaluated version of reverse().
\nIt is useful for when you need to use a URL reversal before your project’s\nURLConf is loaded. Some common cases where this function is necessary are:
\nproviding a reversed URL as the url attribute of a generic class-based\nview.
providing a reversed URL to a decorator (such as the login_url argument\nfor the django.contrib.auth.decorators.permission_required()\ndecorator).
providing a reversed URL as a default value for a parameter in a function’s\nsignature.
resolve()Link to this heading#The resolve() function can be used for resolving URL paths to the\ncorresponding view functions. It has the following signature:
path is the URL path you want to resolve. As with\nreverse(), you don’t need to worry about the urlconf\nparameter. The function returns a ResolverMatch object that allows you\nto access various metadata about the resolved URL.
If the URL does not resolve, the function raises a\nResolver404 exception (a subclass of\nHttp404) .
The view function that would be used to serve the URL
\nThe arguments that would be passed to the view function, as\nparsed from the URL.
\nAll keyword arguments that would be passed to the view function, i.e.\ncaptured_kwargs and\nextra_kwargs.
The captured keyword arguments that would be passed to the view\nfunction, as parsed from the URL.
\nThe additional keyword arguments that would be passed to the view\nfunction.
\nThe name of the URL pattern that matches the URL.
\nThe route of the matching URL pattern.
\nFor example, if path('users/<id>/', ...) is the matching pattern,\nroute will contain 'users/<id>/'.
The list of URL patterns tried before the URL either matched one or\nexhausted available patterns.
\nThe application namespace for the URL pattern that matches the\nURL.
\nThe list of individual namespace components in the full\napplication namespace for the URL pattern that matches the URL.\nFor example, if the app_name is 'foo:bar', then app_names\nwill be ['foo', 'bar'].
The instance namespace for the URL pattern that matches the\nURL.
\nThe list of individual namespace components in the full\ninstance namespace for the URL pattern that matches the URL.\ni.e., if the namespace is foo:bar, then namespaces will be\n['foo', 'bar'].
The name of the view that matches the URL, including the namespace if\nthere is one.
\nA ResolverMatch object can then be interrogated to provide\ninformation about the URL pattern that matches a URL:
# Resolve a URL\nmatch = resolve("/some/path/")\n# Print the URL pattern that matches the URL\nprint(match.url_name)\nA ResolverMatch object can also be assigned to a triple:
func, args, kwargs = resolve("/some/path/")\nOne possible use of resolve() would be to test whether a\nview would raise a Http404 error before redirecting to it:
from urllib.parse import urlsplit\nfrom django.urls import resolve\nfrom django.http import Http404, HttpResponseRedirect\n\n\ndef myview(request):\n next = request.META.get("HTTP_REFERER", None) or "/"\n response = HttpResponseRedirect(next)\n\n # modify the request and response as required, e.g. change locale\n # and set corresponding locale cookie\n\n view, args, kwargs = resolve(urlsplit(next).path)\n kwargs["request"] = request\n try:\n view(*args, **kwargs)\n except Http404:\n return HttpResponseRedirect("/")\n return response\nget_script_prefix()Link to this heading#Normally, you should always use reverse() to define URLs\nwithin your application. However, if your application constructs part of the\nURL hierarchy itself, you may occasionally need to generate URLs. In that\ncase, you need to be able to find the base URL of the Django project within\nits web server (normally, reverse() takes care of this for\nyou). In that case, you can call get_script_prefix(), which will return\nthe script prefix portion of the URL for your Django project. If your Django\nproject is at the root of its web server, this is always "/".