Consider this URLconf, which builds on the example in Chapter 2, Views and URLconfs:

from django.conf.urls import include, url 
from django.contrib import admin 
from mysite.views import hello, current_datetime, hours_ahead 
 
urlpatterns = [ 
      url(r'^admin/', include(admin.site.urls)), 
      url(r'^hello/$', hello), 
      url(r'^time/$', current_datetime), 
      url(r'^time/plus/(d{1,2})/$', hours_ahead), 
      ] 

As explained in Chapter 2, Views and URLconfs, each entry in the URLconf includes its associated view function, passed directly as a function object. This means it's necessary to import the view functions at the top of the module.

But as a Django application grows in complexity, its URLconf grows, too, and keeping those imports can be tedious to manage. (For each new view function, you have to remember to import it, and the import statement tends to get overly long if you use this approach.)

It's possible to avoid that tedium by importing the views module itself. This example URLconf is equivalent to the previous one:

from django.conf.urls import include, url 
from . import views 
 
urlpatterns = [ 
         url(r'^hello/$', views.hello), 
         url(r'^time/$', views.current_datetime), 
         url(r'^time/plus/(d{1,2})/$', views.hours_ahead), 
] 

Speaking of constructing urlpatterns dynamically, you might want to take advantage of this technique to alter your URLconf's behavior while in Django's debug mode. To do this, just check the value of the DEBUG setting at runtime, like so:

from django.conf import settings 
from django.conf.urls import url 
from . import views 
 
urlpatterns = [ 
    url(r'^$', views.homepage), 
    url(r'^(d{4})/([a-z]{3})/$', views.archive_month), 
] 
 
if settings.DEBUG:

    urlpatterns += [url(r'^debuginfo/$', views.debug),]

In this example, the URL /debuginfo/ will only be available if your DEBUG setting is set to True.

The above example used simple, non-named regular-expression groups (via parenthesis) to capture bits of the URL and pass them as positional arguments to a view.

In more advanced usage, it's possible to use named regular-expression groups to capture URL bits and pass them as keyword arguments to a view.

In Python regular expressions, the syntax for named regular-expression groups is (?P<name>pattern), where name is the name of the group and pattern is some pattern to match.

For example, say we have a list of book reviews on our books site, and we want to retrieve reviews for certain dates, or date ranges.

Here's a sample URLconf:

from django.conf.urls import url 
 
from . import views 
 
urlpatterns = [ 
    url(r'^reviews/2003/$', views.special_case_2003), 
    url(r'^reviews/([0-9]{4})/$', views.year_archive), 
    url(r'^reviews/([0-9]{4})/([0-9]{2})/$', views.month_archive), 
    url(r'^reviews/([0-9]{4})/([0-9]{2})/([0-9]+)/$', views.review_detail), 
] 

Example requests:

Here's the above example URLconf, rewritten to use named groups:

from django.conf.urls import url 
 
from . import views 
 
urlpatterns = [ 
    url(r'^reviews/2003/$', views.special_case_2003), 
    url(r'^reviews/(?P<year>[0-9]{4})/$', views.year_archive), 
    url(r'^reviews/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$', views.month_archive), 
    url(r'^reviews/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<day>[0-9]{2})/$', views.review_detail), 
] 

This accomplishes exactly the same thing as the previous example, with one subtle difference: The captured values are passed to view functions as keyword arguments rather than positional arguments. For example:

In practice, this means your URLconfs are slightly more explicit and less prone to argument-order bugs-and you can reorder the arguments in your view's function definitions. Of course, these benefits come at the cost of brevity; some developers find the named-group syntax ugly and too verbose.

The URLconf searches against the requested URL, as a normal Python string. This does not include GET or POST parameters, or the domain name. For example, in a request to http://www.example.com/myapp/, the URLconf will look for myapp/. In a request to http://www.example.com/myapp/?page=3, the URLconf will look for myapp/. The URLconf doesn't look at the request method. In other words, all request methods-POST, GET, HEAD, and so on-will be routed to the same function for the same URL.

Each captured argument is sent to the view as a plain Python string, regardless of what sort of match the regular expression makes. For example, in this URLconf line:

url(r'^reviews/(?P<year>[0-9]{4})/$', views.year_archive), 

...the year argument to views.year_archive() will be a string, not an integer, even though the [0-9]{4} will only match integer strings.

A convenient trick is to specify default parameters for your view's arguments. Here's an example URLconf:

# URLconf 
from django.conf.urls import url 
 
from . import views 
 
urlpatterns = [ 
    url(r'^reviews/$', views.page), 
    url(r'^reviews/page(?P<num>[0-9]+)/$', views.page), 
] 
 
# View (in reviews/views.py) 
def page(request, num="1"): 
    # Output the appropriate page of review entries, according to num. 
    ... 

In the above example, both URL patterns point to the same view-views.page-but the first pattern doesn't capture anything from the URL. If the first pattern matches, the page() function will use its default argument for num, "1". If the second pattern matches, page() will use whatever num value was captured by the regex.