我们在中级篇中学会了如何进行反向解析，但是有这样一个问题，在为 url 命名的时候，名字不能重复，否则会导致各种各样的问题。在 url 还少的时候保证不重名还是比较简单的，但是 url 多起来以后就比较难了。为了解决这样的问题，可以在 url 中加一个前缀。例如，我有一个 url 的名字叫做 ‘comment‘ ，此时，我可以为其加一个前缀，这个前缀通常是 app 名，例如：‘myapp-comment‘。
这也是django所推荐的命名方式，但是这样始终是治标不治本。此时，我们就要学习 django 中 url 命名空间了。
URL 命名空间
简介：
URL 命名空间允许你反查到唯一的命名 URL，即使在不同的应用中使用相同的 URL 名称。（也就是可以在不同的app中使用相同的名称，为有命名困难症的程序员带来了福音）
根据经验，第三方应用应该始终使用带命名空间的URL 。类似地，它还允许你在一个应用有多个实例部署的情况下反查URL。换句话讲，因为一个应用的多个实例共享相同的命名URL，命名空间将提供一种区分这些命名 URL 的方法。
在一个站点上，正确使用 URL 命名空间的 Django 应用可以部署多次。例如，django.contrib.admin 具有一个 AdminSite 类，它允许你很容易地部署多个管理站点的实例。在下面的例子中，我们将讨论在两个不同的地方部署教程中的polls 应用，这样我们可以为两种不同的用户（作者和发布者）提供相同的功能。
一个URL 命名空间有两个部分，它们都是字符串：
- 应用命名空间：
- 它表示正在部署的应用的名称。一个应用的每个实例具有相同的应用命名空间。例如，可以预见Django 的管理站点的应用命名空间是‘admin‘。
- 实例命名空间：
- 它表示应用的一个特定的实例。实例的命名空间在你的全部项目中应该是唯一的。但是，一个实例的命名空间可以和应用的命名空间相同。它用于表示一个应用的默认实例。例如，Django 管理站点实例具有一个默认的实例命名空间‘admin‘。
URL 的命名空间使用‘:‘ 操作符指定。例如，管理站点应用的主页使用‘admin:index‘。它表示‘admin‘ 的一个命名空间和‘index‘ 的一个命名URL。
命名空间也可以嵌套。命名URL‘sports:polls:index‘ 将在命名空间‘polls‘中查找‘index‘，而poll 定义在顶层的命名空间‘sports‘ 中。
反查带命名空间的URL
我们在中级篇中了解到了 url 反查带来的变量，而在中级篇中，都是使用 name 进行反查，这里来看看如何对带命名空间的 url 进行反查。
例子：
from django.conf.urls import include, url
urlpatterns = [
url(r‘^author-polls/‘, include(‘polls.urls‘, namespace=‘author-polls‘, app_name=‘polls‘)),
url(r‘^publisher-polls/‘, include(‘polls.urls‘, namespace=‘publisher-polls‘, app_name=‘polls‘)),
]
from django.conf.urls import url
from . import views
urlpatterns = [
url(r‘^$‘, views.IndexView.as_view(), name=‘index‘),
url(r‘^(?P<pk>\d+)/$‘, views.DetailView.as_view(), name=‘detail‘),
...
]
反查的方法和中级篇的一样，在模板中：
{% url ‘polls:index‘ %}
在基于类的视图的方法中：
reverse(‘polls:index‘, current_app=self.request.resolver_match.namespace)
另外，注意，在模板中的反查需要添加 request 的 current_app 属性，像这样：
def render_to_response(self, context, **response_kwargs):
self.request.current_app = self.request.resolver_match.namespace
return super(DetailView, self).render_to_response(context, **response_kwargs)
这时，会有同学有疑问了， polls 这个应用命名空间设置了两行呀，那 polls 下的 index 到底指的是哪个？
这个时候，就要看 django 的查找顺序了：
1.如果当前有实例，也就是说我们通过 url 访问到了某个处理函数，这个函数进行反向查询的时候，例如我访问的是：author-polls/ ，这个 url 对应的处理函数要进行反向解析，此时它要解析 ‘polls:detail‘。那么将解析到 author-polls/(?P<pk>\d+)/$ 中，也就是有实例的优先在该实例空间中查询。
2.如果没有实例，但是有默认的实例空间，例如 app_name=‘polls‘，namespace=‘polls‘ ，和应用空间同名，这样的就叫做默认实例空间。在没有访问实例的时候，就匹配到默认实例空间中。
3.如果没有实例，也没有默认实例空间，那么谁是最后注册的就选谁，例子中的 namespace=‘publisher-polls‘ 就是最后一个注册的（也就是下面的）。
注意：
因为实例空间要是唯一的，所以使用 namespace：name 的模式应该也是唯一匹配的，例如这里的‘author-polls:index‘ 将永远解析到 ‘author-polls‘ 实例的主页（‘publisher-polls‘ 类似）。
URL 命名空间和被包含的URLconf
被包含的URLconf 的命名空间可以通过两种方式指定。
首先，在你构造你的URL 模式时，你可以提供 应用 和 实例的命名空间给 include() 作为参数。例如
url(r‘^polls/‘, include(‘polls.urls‘, namespace=‘author-polls‘, app_name=‘polls‘)),
这将包含 polls.urls 中定义的URL 到应用命名空间 ‘polls‘中，其实例命名空间为‘author-polls‘。
其次，你可以include 一个包含嵌套命名空间数据的对象。如果你include() 一个url() 实例的列表，那么该对象中包含的URL 将添加到全局命名空间。然而，你还可以include() 一个3个元素的元组：
(<list of url() instances>, <application namespace>, <instance namespace>)
注意这里的应用命名空间和实例命名空间是相反的。
实例:
from django.conf.urls import include, url
from . import views
polls_patterns = [
url(r‘^$‘, views.IndexView.as_view(), name=‘index‘),
url(r‘^(?P<pk>\d+)/$‘, views.DetailView.as_view(), name=‘detail‘),
]
url(r‘^polls/‘, include((polls_patterns, ‘polls‘, ‘author-polls‘))),
这样会包含命名的URL模式进入到给定的应用和实例命名空间中。
这里来总结几个关键函数的用法：
1. include(arg, namespace=None, app_name=None)
arg：可以接受一个字符串，表示被包含的模块在哪里；也可以接受一个列表，这个列表是被包含的 url() 的实例；还可以接受一个元祖，元祖的第一个元素是一个被包含的列表，第二个元素是该列表的应用空间名，第三个元素是实例空间名。
namespace ： 实例命名空间
app_name ： 应用命名空间
2. url(regex, view, kwargs=None, name=None, prefix=‘‘)
regex：要匹配的 url。
view：该 url 的处理函数，可以是一个表示函数位置的字符串， 也可以是一个函数的实例。
kwargs： 一个字典，表示传递多余的参数。
name : 为 url 进行命名。
prefix ： if prefix: view = prefix + ‘.‘ + view 表示在 view 前加上前缀。