django.urls utility functionsLink to this heading#reverse()Link to this heading#If you need to use something similar to the url template tag in\nyour code, Django provides the following function:
viewname can be a URL pattern name or the\ncallable view object. For example, given the following url:
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\nreverse(views.archive)\nIf the URL accepts arguments, you may pass them in args. For example:
from django.urls import reverse\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.\nThis current_app argument is used as a hint to resolve application\nnamespaces into URLs on specific application instances, according to the\nnamespaced URL 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.
reverse_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.
\nThe keyword arguments that would be passed to the view\nfunction, as parsed from the URL.
\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 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 urlparse\nfrom django.urls import resolve\nfrom django.http import Http404, HttpResponseRedirect\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(urlparse(next)[2])\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 "/".