Fixed #26013 -- Moved django.core.urlresolvers to django.urls.

Thanks to Tim Graham for the review.

40 files changed, 166 insertions, 171 deletions

diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index bdf1c4bb45..d560cfed19 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/docs/internals/contributing/writing-code/coding-style.txt
@@ -262,7 +262,7 @@ already been configured).
 So, if there is a module containing some code as follows::
 
     from django.conf import settings
-    from django.core.urlresolvers import get_callable
+    from django.urls import get_callable
 
     default_foo_view = get_callable(settings.FOO_VIEW)
 
diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
index b165450d6a..c03da8fd47 100644
--- a/docs/internals/deprecation.txt
+++ b/docs/internals/deprecation.txt
@@ -128,6 +128,8 @@ details on these changes.
 
 * The ``shell --plain`` option will be removed.
 
+* The ``django.core.urlresolvers`` module will be removed.
+
 .. _deprecation-removed-in-1.10:
 
 1.10
@@ -152,8 +154,7 @@ details on these changes.
 * Using an incorrect count of unpacked values in the ``for`` template tag
   will raise an exception rather than fail silently.
 
-* The ability to :func:`~django.core.urlresolvers.reverse` URLs using a dotted
-  Python path will be removed.
+* The ability to reverse URLs using a dotted Python path will be removed.
 
 * Support for :py:mod:`optparse` will be dropped for custom management commands
   (replaced by :py:mod:`argparse`).
diff --git a/docs/intro/tutorial03.txt b/docs/intro/tutorial03.txt
index 2a6708f37b..93cd2eb4d2 100644
--- a/docs/intro/tutorial03.txt
+++ b/docs/intro/tutorial03.txt
@@ -56,7 +56,7 @@ To get from a URL to a view, Django uses what are known as 'URLconfs'. A
 URLconf maps URL patterns (described as regular expressions) to views.
 
 This tutorial provides basic instruction in the use of URLconfs, and you can
-refer to :mod:`django.core.urlresolvers` for more information.
+refer to :mod:`django.urls` for more information.
 
 Writing more views
 ==================
diff --git a/docs/intro/tutorial04.txt b/docs/intro/tutorial04.txt
index 7c544b7436..201cc7d928 100644
--- a/docs/intro/tutorial04.txt
+++ b/docs/intro/tutorial04.txt
@@ -71,7 +71,7 @@ create a real version. Add the following to ``polls/views.py``:
 
     from django.shortcuts import get_object_or_404, render
     from django.http import HttpResponseRedirect, HttpResponse
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
 
     from .models import Choice, Question
     # ...
@@ -124,13 +124,13 @@ This code includes a few things we haven't covered yet in this tutorial:
   POST data. This tip isn't specific to Django; it's just good Web
   development practice.
 
-* We are using the :func:`~django.core.urlresolvers.reverse` function in the
+* We are using the :func:`~django.urls.reverse` function in the
   :class:`~django.http.HttpResponseRedirect` constructor in this example.
   This function helps avoid having to hardcode a URL in the view function.
   It is given the name of the view that we want to pass control to and the
   variable portion of the URL pattern that points to that view. In this
   case, using the URLconf we set up in :doc:`Tutorial 3 </intro/tutorial03>`,
-  this :func:`~django.core.urlresolvers.reverse` call will return a string like
+  this :func:`~django.urls.reverse` call will return a string like
   ::
 
     '/polls/3/results/'
@@ -264,7 +264,7 @@ views and use Django's generic views instead. To do so, open the
 
     from django.shortcuts import get_object_or_404, render
     from django.http import HttpResponseRedirect
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from django.views import generic
 
     from .models import Choice, Question
diff --git a/docs/intro/tutorial05.txt b/docs/intro/tutorial05.txt
index 5cc4c2a963..45fdb3746d 100644
--- a/docs/intro/tutorial05.txt
+++ b/docs/intro/tutorial05.txt
@@ -362,7 +362,7 @@ With that ready, we can ask the client to do some work for us::
     404
     >>> # on the other hand we should expect to find something at '/polls/'
     >>> # we'll use 'reverse()' rather than a hardcoded URL
-    >>> from django.core.urlresolvers import reverse
+    >>> from django.urls import reverse
     >>> response = client.get(reverse('polls:index'))
     >>> response.status_code
     200
@@ -447,7 +447,7 @@ Add the following to ``polls/tests.py``:
 .. snippet::
     :filename: polls/tests.py
 
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
 
 and we'll create a shortcut function to create questions as well as a new test
 class:
diff --git a/docs/ref/class-based-views/generic-date-based.txt b/docs/ref/class-based-views/generic-date-based.txt
index d8b7933138..b03e34858e 100644
--- a/docs/ref/class-based-views/generic-date-based.txt
+++ b/docs/ref/class-based-views/generic-date-based.txt
@@ -13,7 +13,7 @@ views for displaying drilldown pages for date-based data.
     defined as follows in ``myapp/models.py``::
 
         from django.db import models
-        from django.core.urlresolvers import reverse
+        from django.urls import reverse
 
         class Article(models.Model):
             title = models.CharField(max_length=200)
diff --git a/docs/ref/class-based-views/generic-editing.txt b/docs/ref/class-based-views/generic-editing.txt
index bb83fa597e..d726c0a3cb 100644
--- a/docs/ref/class-based-views/generic-editing.txt
+++ b/docs/ref/class-based-views/generic-editing.txt
@@ -15,7 +15,7 @@ editing content:
     Some of the examples on this page assume that an ``Author`` model has been
     defined as follows in ``myapp/models.py``::
 
-        from django.core.urlresolvers import reverse
+        from django.urls import reverse
         from django.db import models
 
         class Author(models.Model):
@@ -227,7 +227,7 @@ DeleteView
     **Example myapp/views.py**::
 
         from django.views.generic.edit import DeleteView
-        from django.core.urlresolvers import reverse_lazy
+        from django.urls import reverse_lazy
         from myapp.models import Author
 
         class AuthorDelete(DeleteView):
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
index a36859c012..35c787ec1b 100644
--- a/docs/ref/contrib/admin/index.txt
+++ b/docs/ref/contrib/admin/index.txt
@@ -1252,7 +1252,7 @@ subclass::
     For example::
 
         from django.contrib import admin
-        from django.core.urlresolvers import reverse
+        from django.urls import reverse
 
         class PersonAdmin(admin.ModelAdmin):
             def view_on_site(self, obj):
@@ -2883,9 +2883,9 @@ So - if you wanted to get a reference to the Change view for a particular
 ``Choice`` object (from the polls application) in the default admin, you would
 call::
 
-    >>> from django.core import urlresolvers
+    >>> from django.urls import reverse
     >>> c = Choice.objects.get(...)
-    >>> change_url = urlresolvers.reverse('admin:polls_choice_change', args=(c.id,))
+    >>> change_url = reverse('admin:polls_choice_change', args=(c.id,))
 
 This will find the first registered instance of the admin application
 (whatever the instance name), and resolve to the view for changing
@@ -2896,8 +2896,7 @@ that instance as a ``current_app`` hint to the reverse call. For example,
 if you specifically wanted the admin view from the admin instance named
 ``custom``, you would need to call::
 
-    >>> change_url = urlresolvers.reverse('admin:polls_choice_change',
-    ...                                   args=(c.id,), current_app='custom')
+    >>> change_url = reverse('admin:polls_choice_change', args=(c.id,), current_app='custom')
 
 For more details, see the documentation on :ref:`reversing namespaced URLs
 <topics-http-reversing-url-namespaces>`.
diff --git a/docs/ref/contrib/sitemaps.txt b/docs/ref/contrib/sitemaps.txt
index a4dbb3d1a1..822b338e2e 100644
--- a/docs/ref/contrib/sitemaps.txt
+++ b/docs/ref/contrib/sitemaps.txt
@@ -300,13 +300,12 @@ Sitemap for static views
 
 Often you want the search engine crawlers to index views which are neither
 object detail pages nor flatpages. The solution is to explicitly list URL
-names for these views in ``items`` and call
-:func:`~django.core.urlresolvers.reverse` in the ``location`` method of
-the sitemap. For example::
+names for these views in ``items`` and call :func:`~django.urls.reverse` in
+the ``location`` method of the sitemap. For example::
 
     # sitemaps.py
     from django.contrib import sitemaps
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
 
     class StaticViewSitemap(sitemaps.Sitemap):
         priority = 0.5
diff --git a/docs/ref/contrib/syndication.txt b/docs/ref/contrib/syndication.txt
index 683b5cdc08..080b0a526c 100644
--- a/docs/ref/contrib/syndication.txt
+++ b/docs/ref/contrib/syndication.txt
@@ -53,7 +53,7 @@ This simple example, taken from a hypothetical police beat news site describes
 a feed of the latest five news items::
 
     from django.contrib.syndication.views import Feed
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from policebeat.models import NewsItem
 
     class LatestEntriesFeed(Feed):
diff --git a/docs/ref/exceptions.txt b/docs/ref/exceptions.txt
index 7e03c42286..37424fe7c6 100644
--- a/docs/ref/exceptions.txt
+++ b/docs/ref/exceptions.txt
@@ -84,7 +84,7 @@ Django core exception classes are defined in ``django.core.exceptions``.
 .. exception:: ViewDoesNotExist
 
     The :exc:`ViewDoesNotExist` exception is raised by
-    :mod:`django.core.urlresolvers` when a requested view does not exist.
+    :mod:`django.urls` when a requested view does not exist.
 
 ``MiddlewareNotUsed``
 ---------------------
@@ -142,12 +142,18 @@ or model are classified as ``NON_FIELD_ERRORS``. This constant is used
 as a key in dictionaries that otherwise map fields to their respective
 list of errors.
 
-.. currentmodule:: django.core.urlresolvers
+.. currentmodule:: django.urls
 
 URL Resolver exceptions
 =======================
 
-URL Resolver exceptions are defined in ``django.core.urlresolvers``.
+URL Resolver exceptions are defined in ``django.urls``.
+
+.. deprecated:: 1.10
+
+    In older versions, these exceptions are located in
+    ``django.core.urlresolvers``. Importing from the old location will continue
+    to work until Django 2.0.
 
 ``Resolver404``
 ---------------
@@ -155,18 +161,17 @@ URL Resolver exceptions are defined in ``django.core.urlresolvers``.
 .. exception:: Resolver404
 
     The :exc:`Resolver404` exception is raised by
-    :func:`django.core.urlresolvers.resolve()` if the path passed to
-    ``resolve()`` doesn't map to a view. It's a subclass of
-    :class:`django.http.Http404`.
+    :func:`~django.urls.resolve()` if the path passed to ``resolve()`` doesn't
+    map to a view. It's a subclass of :class:`django.http.Http404`.
 
 ``NoReverseMatch``
 ------------------
 
 .. exception:: NoReverseMatch
 
-    The :exc:`NoReverseMatch` exception is raised by
-    :mod:`django.core.urlresolvers` when a matching URL in your URLconf
-    cannot be identified based on the parameters supplied.
+    The :exc:`NoReverseMatch` exception is raised by :mod:`django.urls` when a
+    matching URL in your URLconf cannot be identified based on the parameters
+    supplied.
 
 .. currentmodule:: django.db
 
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index e8849d7405..f1fc3e60e6 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -672,14 +672,14 @@ For example::
     def get_absolute_url(self):
         return "/people/%i/" % self.id
 
-(Whilst this code is correct and simple, it may not be the most portable way to
-write this kind of method. The :func:`~django.core.urlresolvers.reverse`
-function is usually the best approach.)
+While this code is correct and simple, it may not be the most portable way to
+to write this kind of method. The :func:`~django.urls.reverse` function is
+usually the best approach.
 
 For example::
 
     def get_absolute_url(self):
-        from django.core.urlresolvers import reverse
+        from django.urls import reverse
         return reverse('people.views.details', args=[str(self.id)])
 
 One place Django uses ``get_absolute_url()`` is in the admin app. If an object
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 675a47d8d0..99a531adfb 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -160,11 +160,11 @@ All attributes should be considered read-only, unless stated otherwise.
 
 .. attribute:: HttpRequest.resolver_match
 
-    An instance of :class:`~django.core.urlresolvers.ResolverMatch` representing
-    the resolved url. This attribute is only set after url resolving took place,
-    which means it's available in all views but not in middleware methods which
-    are executed before url resolving takes place (like ``process_request``, you
-    can use ``process_view`` instead).
+    An instance of :class:`~django.urls.ResolverMatch` representing the
+    resolved URL. This attribute is only set after URL resolving took place,
+    which means it's available in all views but not in middleware methods
+    which are executed before URL resolving takes place (like
+    ``process_request()``, you can use ``process_view()`` instead).
 
 Attributes set by application code
 ----------------------------------
@@ -175,7 +175,7 @@ application.
 .. attribute:: HttpRequest.current_app
 
     The :ttag:`url` template tag will use its value as the ``current_app``
-    argument to :func:`~django.core.urlresolvers.reverse()`.
+    argument to :func:`~django.urls.reverse()`.
 
 .. attribute:: HttpRequest.urlconf
 
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
index da6df4472f..67e19769ad 100644
--- a/docs/ref/templates/builtins.txt
+++ b/docs/ref/templates/builtins.txt
@@ -1024,8 +1024,8 @@ such as this:
 The template tag will output the string ``/clients/client/123/``.
 
 Note that if the URL you're reversing doesn't exist, you'll get an
-:exc:`~django.core.urlresolvers.NoReverseMatch` exception raised, which will
-cause your site to display an error page.
+:exc:`~django.urls.NoReverseMatch` exception raised, which will cause your
+site to display an error page.
 
 If you'd like to retrieve a URL without displaying it, you can use a slightly
 different call::
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
index 7c359da315..0ef12aecd9 100644
--- a/docs/ref/unicode.txt
+++ b/docs/ref/unicode.txt
@@ -290,8 +290,8 @@ Taking care in ``get_absolute_url()``
 
 URLs can only contain ASCII characters. If you're constructing a URL from
 pieces of data that might be non-ASCII, be careful to encode the results in a
-way that is suitable for a URL. The :func:`~django.core.urlresolvers.reverse`
-function handles this for you automatically.
+way that is suitable for a URL. The :func:`~django.urls.reverse` function
+handles this for you automatically.
 
 If you're constructing a URL manually (i.e., *not* using the ``reverse()``
 function), you'll need to take care of the encoding yourself. In this case,
diff --git a/docs/ref/urlresolvers.txt b/docs/ref/urlresolvers.txt
index c9a1cf3af3..11c353502f 100644
--- a/docs/ref/urlresolvers.txt
+++ b/docs/ref/urlresolvers.txt
@@ -1,8 +1,14 @@
-==============================================
-``django.core.urlresolvers`` utility functions
-==============================================
+=================================
+``django.urls`` utility functions
+=================================
 
-.. module:: django.core.urlresolvers
+.. module:: django.urls
+
+.. deprecated:: 1.10
+
+    In older versions, these functions are located in
+    ``django.core.urlresolvers``. Importing from the old location will continue
+    to work until Django 2.0.
 
 reverse()
 ---------
@@ -31,7 +37,7 @@ you can use any of the following to reverse the URL::
 
 If the URL accepts arguments, you may pass them in ``args``. For example::
 
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
 
     def myview(request):
         return HttpResponseRedirect(reverse('arch-summary', args=[1945]))
@@ -44,7 +50,7 @@ You can also pass ``kwargs`` instead of ``args``. For example::
 ``args`` and ``kwargs`` cannot be passed to ``reverse()`` at the same time.
 
 If no match can be made, ``reverse()`` raises a
-:class:`~django.core.urlresolvers.NoReverseMatch` exception.
+:class:`~django.urls.NoReverseMatch` exception.
 
 The ``reverse()`` function can reverse a large variety of regular expression
 patterns for URLs, but not every possible one. The main restriction at the
@@ -103,13 +109,12 @@ corresponding view functions. It has the following signature:
 .. function:: resolve(path, urlconf=None)
 
 ``path`` is the URL path you want to resolve. As with
-:func:`~django.core.urlresolvers.reverse`, you don't need to
-worry about the ``urlconf`` parameter. The function returns a
-:class:`ResolverMatch` object that allows you
-to access various meta-data about the resolved URL.
+:func:`~django.urls.reverse`, you don't need to worry about the ``urlconf``
+parameter. The function returns a :class:`ResolverMatch` object that allows you
+to access various metadata about the resolved URL.
 
 If the URL does not resolve, the function raises a
-:exc:`~django.core.urlresolvers.Resolver404` exception (a subclass of
+:exc:`~django.urls.Resolver404` exception (a subclass of
 :class:`~django.http.Http404`) .
 
 .. class:: ResolverMatch
@@ -175,10 +180,10 @@ A :class:`ResolverMatch` object can also be assigned to a triple::
 
     func, args, kwargs = resolve('/some/path/')
 
-One possible use of :func:`~django.core.urlresolvers.resolve` would be to test
-whether a view would raise a ``Http404`` error before redirecting to it::
+One possible use of :func:`~django.urls.resolve` would be to test whether a
+view would raise a ``Http404`` error before redirecting to it::
 
-    from django.core.urlresolvers import resolve
+    from django.urls import resolve
     from django.http import HttpResponseRedirect, Http404
     from django.utils.six.moves.urllib.parse import urlparse
 
@@ -202,12 +207,11 @@ get_script_prefix()
 
 .. function:: get_script_prefix()
 
-Normally, you should always use :func:`~django.core.urlresolvers.reverse` to
-define URLs within your application. However, if your application constructs
-part of the URL hierarchy itself, you may occasionally need to generate URLs.
-In that case, you need to be able to find the base URL of the Django project
-within its Web server (normally, :func:`~django.core.urlresolvers.reverse`
-takes care of this for you). In that case, you can call
-``get_script_prefix()``, which will return the script prefix portion of the URL
-for your Django project. If your Django project is at the root of its web
-server, this is always ``"/"``.
+Normally, you should always use :func:`~django.urls.reverse` to define URLs
+within your application. However, if your application constructs part of the
+URL hierarchy itself, you may occasionally need to generate URLs. In that
+case, you need to be able to find the base URL of the Django project within
+its Web server (normally, :func:`~django.urls.reverse` takes care of this for
+you). In that case, you can call ``get_script_prefix()``, which will return
+the script prefix portion of the URL for your Django project. If your Django
+project is at the root of its web server, this is always ``"/"``.
diff --git a/docs/releases/1.1.txt b/docs/releases/1.1.txt
index 11e5ceb0d4..63b8c9ab13 100644
--- a/docs/releases/1.1.txt
+++ b/docs/releases/1.1.txt
@@ -380,11 +380,11 @@ Other new features and changes introduced since Django 1.0 include:
   order to allow fine-grained control of when and where the CSRF processing
   takes place.
 
-* :func:`~django.core.urlresolvers.reverse` and code which uses it (e.g., the
-  ``{% url %}`` template tag) now works with URLs in Django's administrative
-  site, provided that the admin URLs are set up via ``include(admin.site.urls)``
-  (sending admin requests to the ``admin.site.root`` view still works, but URLs
-  in the admin will not be "reversible" when configured this way).
+* ``reverse()`` and code which uses it (e.g., the ``{% url %}`` template tag)
+  now works with URLs in Django's administrative site, provided that the admin
+  URLs are set up via ``include(admin.site.urls)`` (sending admin requests to
+  the ``admin.site.root`` view still works, but URLs in the admin will not be
+  "reversible" when configured this way).
 
 * The ``include()`` function in Django URLconf modules can now accept sequences
   of URL patterns (generated by ``patterns()``) in addition to module names.
diff --git a/docs/releases/1.10.txt b/docs/releases/1.10.txt
index 34294e901a..3143d9e0cd 100644
--- a/docs/releases/1.10.txt
+++ b/docs/releases/1.10.txt
@@ -460,6 +460,9 @@ Miscellaneous
 * The ``shell --plain`` option is deprecated in favor of ``-i python`` or
   ``--interface python``.
 
+* Importing from the ``django.core.urlresolvers`` module is deprecated in
+  favor of its new location, :mod:`django.urls`.
+
 .. _removed-features-1.10:
 
 Features removed in 1.10
@@ -485,8 +488,8 @@ removed in Django 1.10 (please see the :ref:`deprecation timeline
 * Using an incorrect count of unpacked values in the ``for`` template tag
   raises an exception rather than failing silently.
 
-* The ability to :func:`~django.core.urlresolvers.reverse` URLs using a dotted
-  Python path is removed.
+* The ability to :func:`~django.urls.reverse` URLs using a dotted Python path
+  is removed.
 
 * Support for ``optparse`` is dropped for custom management commands.
 
diff --git a/docs/releases/1.4.11.txt b/docs/releases/1.4.11.txt
index d6d65f7789..990f511e71 100644
--- a/docs/releases/1.4.11.txt
+++ b/docs/releases/1.4.11.txt
@@ -16,14 +16,12 @@ Django's URL handling is based on a mapping of regex patterns
 consists of matching a requested URL against those patterns to
 determine the appropriate view to invoke.
 
-Django also provides a convenience function --
-:func:`~django.core.urlresolvers.reverse` -- which performs this process
-in the opposite direction. The ``reverse()`` function takes
-information about a view and returns a URL which would invoke that
-view. Use of ``reverse()`` is encouraged for application developers,
-as the output of ``reverse()`` is always based on the current URL
-patterns, meaning developers do not need to change other code when
-making changes to URLs.
+Django also provides a convenience function -- ``reverse()`` -- which performs
+this process in the opposite direction. The ``reverse()`` function takes
+information about a view and returns a URL which would invoke that view. Use
+of ``reverse()`` is encouraged for application developers, as the output of
+``reverse()`` is always based on the current URL patterns, meaning developers
+do not need to change other code when making changes to URLs.
 
 One argument signature for ``reverse()`` is to pass a dotted Python
 path to the desired view. In this situation, Django will import the
diff --git a/docs/releases/1.4.12.txt b/docs/releases/1.4.12.txt
index c15842b3f4..7c7e65a577 100644
--- a/docs/releases/1.4.12.txt
+++ b/docs/releases/1.4.12.txt
@@ -9,6 +9,5 @@ Django 1.4.12 fixes a regression in the 1.4.11 security release.
 Bugfixes
 ========
 
-* Restored the ability to :meth:`~django.core.urlresolvers.reverse` views
-  created using :func:`functools.partial()`
-  (:ticket:`22486`)
+* Restored the ability to ``reverse()`` views created using
+  :func:`functools.partial()` (:ticket:`22486`).
diff --git a/docs/releases/1.4.14.txt b/docs/releases/1.4.14.txt
index d5d1a66f89..5e8f0c16b8 100644
--- a/docs/releases/1.4.14.txt
+++ b/docs/releases/1.4.14.txt
@@ -6,8 +6,8 @@ Django 1.4.14 release notes
 
 Django 1.4.14 fixes several security issues in 1.4.13.
 
-:func:`~django.core.urlresolvers.reverse()` could generate URLs pointing to other hosts
-=======================================================================================
+``reverse()`` could generate URLs pointing to other hosts
+=========================================================
 
 In certain situations, URL reversing could generate scheme-relative URLs  (URLs
 starting with two slashes), which could unexpectedly redirect a user  to a
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index 9f73a42ae6..f56db541a7 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -371,8 +371,8 @@ Django 1.4 to store the wizard's state in the user's cookies.
 ``reverse_lazy``
 ~~~~~~~~~~~~~~~~
 
-A lazily evaluated version of :func:`django.core.urlresolvers.reverse` was
-added to allow using URL reversals before the project's URLconf gets loaded.
+A lazily evaluated version of ``reverse()`` was added to allow using URL
+reversals before the project's URLconf gets loaded.
 
 Translating URL patterns
 ~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/releases/1.5.6.txt b/docs/releases/1.5.6.txt
index 7c3cd3a75d..915dd7e22a 100644
--- a/docs/releases/1.5.6.txt
+++ b/docs/releases/1.5.6.txt
@@ -15,14 +15,12 @@ Django's URL handling is based on a mapping of regex patterns
 consists of matching a requested URL against those patterns to
 determine the appropriate view to invoke.
 
-Django also provides a convenience function --
-:func:`~django.core.urlresolvers.reverse` -- which performs this process
-in the opposite direction. The ``reverse()`` function takes
-information about a view and returns a URL which would invoke that
-view. Use of ``reverse()`` is encouraged for application developers,
-as the output of ``reverse()`` is always based on the current URL
-patterns, meaning developers do not need to change other code when
-making changes to URLs.
+Django also provides a convenience function -- ``reverse()`` -- which performs
+this process in the opposite direction. The ``reverse()`` function takes
+information about a view and returns a URL which would invoke that view. Use
+of ``reverse()`` is encouraged for application developers, as the output of
+``reverse()`` is always based on the current URL patterns, meaning developers
+do not need to change other code when making changes to URLs.
 
 One argument signature for ``reverse()`` is to pass a dotted Python
 path to the desired view. In this situation, Django will import the
diff --git a/docs/releases/1.5.7.txt b/docs/releases/1.5.7.txt
index a650a9b82d..30611527d7 100644
--- a/docs/releases/1.5.7.txt
+++ b/docs/releases/1.5.7.txt
@@ -9,5 +9,5 @@ Django 1.5.7 fixes a regression in the 1.5.6 security release.
 Bugfixes
 ========
 
-* Restored the ability to :meth:`~django.core.urlresolvers.reverse` views
-  created using :func:`functools.partial()` (:ticket:`22486`).
+* Restored the ability to ``reverse()`` views created using
+  :func:`functools.partial()` (:ticket:`22486`).
diff --git a/docs/releases/1.5.9.txt b/docs/releases/1.5.9.txt
index 9942ba081f..a2ccc16567 100644
--- a/docs/releases/1.5.9.txt
+++ b/docs/releases/1.5.9.txt
@@ -6,8 +6,8 @@ Django 1.5.9 release notes
 
 Django 1.5.9 fixes several security issues in 1.5.8.
 
-:func:`~django.core.urlresolvers.reverse()` could generate URLs pointing to other hosts
-=======================================================================================
+``reverse()`` could generate URLs pointing to other hosts
+=========================================================
 
 In certain situations, URL reversing could generate scheme-relative URLs  (URLs
 starting with two slashes), which could unexpectedly redirect a user  to a
diff --git a/docs/releases/1.5.txt b/docs/releases/1.5.txt
index 4b3e286f2b..9a0b036b04 100644
--- a/docs/releases/1.5.txt
+++ b/docs/releases/1.5.txt
@@ -293,8 +293,8 @@ Django 1.5 also includes several smaller improvements worth noting:
   objects fetched into memory. See :meth:`QuerySet.delete()
   <django.db.models.query.QuerySet.delete>` for details.
 
-* An instance of :class:`~django.core.urlresolvers.ResolverMatch` is stored on
-  the request as ``resolver_match``.
+* An instance of ``ResolverMatch`` is stored on the request as
+  ``resolver_match``.
 
 * By default, all logging messages reaching the ``django`` logger when
   :setting:`DEBUG` is ``True`` are sent to the console (unless you redefine the
diff --git a/docs/releases/1.6.3.txt b/docs/releases/1.6.3.txt
index 80438acb4b..0cba7d59af 100644
--- a/docs/releases/1.6.3.txt
+++ b/docs/releases/1.6.3.txt
@@ -15,14 +15,12 @@ Django's URL handling is based on a mapping of regex patterns
 consists of matching a requested URL against those patterns to
 determine the appropriate view to invoke.
 
-Django also provides a convenience function --
-:func:`~django.core.urlresolvers.reverse` -- which performs this process
-in the opposite direction. The ``reverse()`` function takes
-information about a view and returns a URL which would invoke that
-view. Use of ``reverse()`` is encouraged for application developers,
-as the output of ``reverse()`` is always based on the current URL
-patterns, meaning developers do not need to change other code when
-making changes to URLs.
+Django also provides a convenience function -- ``reverse()`` -- which performs
+this process in the opposite direction. The ``reverse()`` function takes
+information about a view and returns a URL which would invoke that view. Use
+of ``reverse()`` is encouraged for application developers, as the output of
+``reverse()`` is always based on the current URL patterns, meaning developers
+do not need to change other code when making changes to URLs.
 
 One argument signature for ``reverse()`` is to pass a dotted Python
 path to the desired view. In this situation, Django will import the
diff --git a/docs/releases/1.6.4.txt b/docs/releases/1.6.4.txt
index ad927cce74..bd437650f6 100644
--- a/docs/releases/1.6.4.txt
+++ b/docs/releases/1.6.4.txt
@@ -13,10 +13,8 @@ Bugfixes
   cookie format of Django 1.4 and earlier to facilitate upgrading to 1.6 from
   1.4 (:ticket:`22426`).
 
-* Restored the ability to :meth:`~django.core.urlresolvers.reverse` views
-  created using :func:`functools.partial()`
-  (:ticket:`22486`).
+* Restored the ability to ``reverse()`` views created using
+  :func:`functools.partial()` (:ticket:`22486`).
 
 * Fixed the ``object_id`` of the ``LogEntry`` that's created after a user
-  password change in the admin
-  (:ticket:`22515`).
+  password change in the admin (:ticket:`22515`).
diff --git a/docs/releases/1.6.6.txt b/docs/releases/1.6.6.txt
index 6081cbc229..42ad2f8b5f 100644
--- a/docs/releases/1.6.6.txt
+++ b/docs/releases/1.6.6.txt
@@ -6,8 +6,8 @@ Django 1.6.6 release notes
 
 Django 1.6.6 fixes several security issues and bugs in 1.6.5.
 
-:func:`~django.core.urlresolvers.reverse()` could generate URLs pointing to other hosts
-=======================================================================================
+``reverse()`` could generate URLs pointing to other hosts
+=========================================================
 
 In certain situations, URL reversing could generate scheme-relative URLs  (URLs
 starting with two slashes), which could unexpectedly redirect a user  to a
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 23de67ee76..6e03178620 100644
--- a/docs/releases/1.6.txt
+++ b/docs/releases/1.6.txt
@@ -583,16 +583,17 @@ be at the end of a line. If they are not, the comments are ignored and
     {{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
     <h1>{% trans "Welcome" %}</h1>
 
-Quoting in :func:`~django.core.urlresolvers.reverse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Quoting in ``reverse()``
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 When reversing URLs, Django didn't apply :func:`~django.utils.http.urlquote`
 to arguments before interpolating them in URL patterns. This bug is fixed in
 Django 1.6. If you worked around this bug by applying URL quoting before
-passing arguments to :func:`~django.core.urlresolvers.reverse`, this may
-result in double-quoting. If this happens, simply remove the URL quoting from
-your code. You will also have to replace special characters in URLs used in
-:func:`~django.test.SimpleTestCase.assertRedirects` with their encoded versions.
+passing arguments to ``reverse()``, this may result in double-quoting. If this
+happens, simply remove the URL quoting from your code. You will also have to
+replace special characters in URLs used in
+:func:`~django.test.SimpleTestCase.assertRedirects` with their encoded
+versions.
 
 Storage of IP addresses in the comments app
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -902,12 +903,12 @@ Miscellaneous
   stored as ``null``. Previously, storing a ``blank`` value in a field which
   did not allow ``null`` would cause a database exception at runtime.
 
-* If a :class:`~django.core.urlresolvers.NoReverseMatch` exception is raised
-  from a method when rendering a template, it is not silenced. For example,
-  ``{{ obj.view_href }}`` will cause template rendering to fail if
-  ``view_href()`` raises ``NoReverseMatch``. There is no change to the
-  :ttag:`{% url %}<url>` tag, it causes template rendering to fail like always
-  when ``NoReverseMatch`` is raised.
+* If a ``NoReverseMatch`` exception is raised from a method when rendering a
+  template, it is not silenced. For example, ``{{ obj.view_href }}`` will
+  cause template rendering to fail if ``view_href()`` raises 
+  ``NoReverseMatch``. There is no change to the :ttag:`{% url %}<url>` tag, it
+  causes template rendering to fail like always when ``NoReverseMatch`` is
+  raised.
 
 * :meth:`django.test.Client.logout` now calls
   :meth:`django.contrib.auth.logout` which will send the
diff --git a/docs/releases/1.7.3.txt b/docs/releases/1.7.3.txt
index 2f3c9c7f49..f8e0dc8b81 100644
--- a/docs/releases/1.7.3.txt
+++ b/docs/releases/1.7.3.txt
@@ -82,8 +82,7 @@ Bugfixes
   (:ticket:`23815`).
 
 * Fixed a crash in the ``django.contrib.auth.redirect_to_login`` view when
-  passing a :func:`~django.core.urlresolvers.reverse_lazy` result on Python 3
-  (:ticket:`24097`).
+  passing a ``reverse_lazy()`` result on Python 3 (:ticket:`24097`).
 
 * Added correct formats for Greek (``el``) (:ticket:`23967`).
 
diff --git a/docs/releases/1.8.txt b/docs/releases/1.8.txt
index 4abdf63f59..d91b01df46 100644
--- a/docs/releases/1.8.txt
+++ b/docs/releases/1.8.txt
@@ -1112,9 +1112,8 @@ Miscellaneous
 * The default max size of the Oracle test tablespace has increased from 300M
   (or 200M, before 1.7.2) to 500M.
 
-* :func:`~django.core.urlresolvers.reverse` and
-  :func:`~django.core.urlresolvers.reverse_lazy` now return Unicode strings
-  instead of byte strings.
+* ``reverse()`` and ``reverse_lazy()`` now return Unicode strings instead of
+  byte strings.
 
 * The ``CacheClass`` shim has been removed from all cache backends.
   These aliases were provided for backwards compatibility with Django 1.3.
@@ -1334,8 +1333,8 @@ Using an incorrect count of unpacked values in the :ttag:`for` template tag
 Using an incorrect count of unpacked values in :ttag:`for` tag will raise an
 exception rather than fail silently in Django 1.10.
 
-Passing a dotted path to :func:`~django.core.urlresolvers.reverse()` and :ttag:`url`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Passing a dotted path to ``reverse()`` and :ttag:`url`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Reversing URLs by Python path is an expensive operation as it causes the
 path being reversed to be imported. This behavior has also resulted in a
diff --git a/docs/releases/1.9.txt b/docs/releases/1.9.txt
index 381ea31138..c01ca94ec4 100644
--- a/docs/releases/1.9.txt
+++ b/docs/releases/1.9.txt
@@ -1083,12 +1083,10 @@ Miscellaneous
   :attr:`~django.test.SimpleTestCase.allow_database_queries` class attribute
   to ``True`` on your test class.
 
-* :attr:`ResolverMatch.app_name
-  <django.core.urlresolvers.ResolverMatch.app_name>` was changed to contain
-  the full namespace path in the case of nested namespaces. For consistency
-  with :attr:`ResolverMatch.namespace
-  <django.core.urlresolvers.ResolverMatch.namespace>`, the empty value is now
-  an empty string instead of ``None``.
+* ``ResolverMatch.app_name`` was changed to contain the full namespace path in
+  the case of nested namespaces. For consistency with
+  ``ResolverMatch.namespace``, the empty value is now an empty string instead
+  of ``None``.
 
 * For security hardening, session keys must be at least 8 characters.
 
diff --git a/docs/topics/class-based-views/generic-editing.txt b/docs/topics/class-based-views/generic-editing.txt
index 9a9c4b7052..f5fa2ffcdb 100644
--- a/docs/topics/class-based-views/generic-editing.txt
+++ b/docs/topics/class-based-views/generic-editing.txt
@@ -98,7 +98,7 @@ First we need to add :meth:`~django.db.models.Model.get_absolute_url()` to our
 .. snippet::
     :filename: models.py
 
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from django.db import models
 
     class Author(models.Model):
@@ -115,7 +115,7 @@ here; we don't have to write any logic ourselves:
     :filename: views.py
 
     from django.views.generic.edit import CreateView, UpdateView, DeleteView
-    from django.core.urlresolvers import reverse_lazy
+    from django.urls import reverse_lazy
     from myapp.models import Author
 
     class AuthorCreate(CreateView):
@@ -131,8 +131,8 @@ here; we don't have to write any logic ourselves:
         success_url = reverse_lazy('author-list')
 
 .. note::
-    We have to use :func:`~django.core.urlresolvers.reverse_lazy` here, not
-    just ``reverse`` as the urls are not loaded when the file is imported.
+    We have to use :func:`~django.urls.reverse_lazy` here, not just
+    ``reverse()`` as the urls are not loaded when the file is imported.
 
 The ``fields`` attribute works the same way as the ``fields`` attribute on the
 inner ``Meta`` class on :class:`~django.forms.ModelForm`. Unless you define the
diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt
index 1dd8b04bb5..5212381a65 100644
--- a/docs/topics/class-based-views/mixins.txt
+++ b/docs/topics/class-based-views/mixins.txt
@@ -225,7 +225,7 @@ We'll demonstrate this with the ``Author`` model we used in the
     :filename: views.py
 
     from django.http import HttpResponseForbidden, HttpResponseRedirect
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from django.views.generic import View
     from django.views.generic.detail import SingleObjectMixin
     from books.models import Author
@@ -445,7 +445,7 @@ Our new ``AuthorDetail`` looks like this::
 
     from django import forms
     from django.http import HttpResponseForbidden
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from django.views.generic import DetailView
     from django.views.generic.edit import FormMixin
     from books.models import Author
@@ -541,7 +541,7 @@ can find the author we're talking about, and we have to remember to set
 ``template_name`` to ensure that form errors will render the same
 template as ``AuthorDisplay`` is using on ``GET``::
 
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from django.http import HttpResponseForbidden
     from django.views.generic import FormView
     from django.views.generic.detail import SingleObjectMixin
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 8c11514507..7faef87766 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -103,9 +103,8 @@ This example is equivalent to::
    * A model: the model's :meth:`~django.db.models.Model.get_absolute_url()`
      function will be called.
 
-   * A view name, possibly with arguments: :func:`urlresolvers.reverse
-     <django.core.urlresolvers.reverse>` will be used to reverse-resolve the
-     name.
+   * A view name, possibly with arguments: :func:`~django.urls.reverse` will be
+     used to reverse-resolve the name.
 
    * An absolute or relative URL, which will be used as-is for the redirect
      location.
@@ -131,7 +130,7 @@ You can use the :func:`redirect` function in a number of ways.
 
 2. By passing the name of a view and optionally some positional or
    keyword arguments; the URL will be reverse resolved using the
-   :func:`~django.core.urlresolvers.reverse` method::
+   :func:`~django.urls.reverse` method::
 
         def my_view(request):
             ...
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index 2ec66de53f..068b91bf60 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -533,8 +533,7 @@ layers where URLs are needed:
 
 * In templates: Using the :ttag:`url` template tag.
 
-* In Python code: Using the :func:`django.core.urlresolvers.reverse`
-  function.
+* In Python code: Using the :func:`~django.urls.reverse` function.
 
 * In higher level code related to handling of URLs of Django model instances:
   The :meth:`~django.db.models.Model.get_absolute_url` method.
@@ -571,7 +570,7 @@ You can obtain these in template code by using:
 
 Or in Python code::
 
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from django.http import HttpResponseRedirect
 
     def redirect_to_year(request):
@@ -671,8 +670,8 @@ the fully qualified name into parts and then tries the following lookup:
 
 2. If there is a current application defined, Django finds and returns the URL
    resolver for that instance. The current application can be specified with
-   the ``current_app`` argument to the
-   :func:`~django.core.urlresolvers.reverse()` function.
+   the ``current_app`` argument to the :func:`~django.urls.reverse()`
+   function.
 
    The :ttag:`url` template tag uses the namespace of the currently resolved
    view as the current application in a
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index 9057cebade..a73a15da4c 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -1360,7 +1360,7 @@ After defining these URL patterns, Django will automatically add the
 language prefix to the URL patterns that were added by the ``i18n_patterns``
 function. Example::
 
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from django.utils.translation import activate
 
     >>> activate('en')
@@ -1414,11 +1414,10 @@ URL patterns can also be marked translatable using the
         url(_(r'^news/'), include(news_patterns, namespace='news')),
     )
 
-After you've created the translations, the
-:func:`~django.core.urlresolvers.reverse` function will return the URL in the
-active language. Example::
+After you've created the translations, the :func:`~django.urls.reverse`
+function will return the URL in the active language. Example::
 
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
     from django.utils.translation import activate
 
     >>> activate('en')
diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt
index e830434468..3aaa017a25 100644
--- a/docs/topics/templates.txt
+++ b/docs/topics/templates.txt
@@ -411,7 +411,7 @@ For example, you can create ``myproject/jinja2.py`` with this content::
     from __future__ import absolute_import  # Python 2 only
 
     from django.contrib.staticfiles.storage import staticfiles_storage
-    from django.core.urlresolvers import reverse
+    from django.urls import reverse
 
     from jinja2 import Environment
 
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index f9e302a0c1..d66f8df5ba 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -507,9 +507,8 @@ Specifically, a ``Response`` object has the following attributes:
 
     .. attribute:: resolver_match
 
-        An instance of :class:`~django.core.urlresolvers.ResolverMatch` for the
-        response. You can use the
-        :attr:`~django.core.urlresolvers.ResolverMatch.func` attribute, for
+        An instance of :class:`~django.urls.ResolverMatch` for the response.
+        You can use the :attr:`~django.urls.ResolverMatch.func` attribute, for
         example, to verify the view that served the response::
 
             # my_view here is a function based view
@@ -520,7 +519,7 @@ Specifically, a ``Response`` object has the following attributes:
             self.assertEqual(response.resolver_match.func.__name__, MyView.as_view().__name__)
 
         If the given URL is not found, accessing this attribute will raise a
-        :exc:`~django.core.urlresolvers.Resolver404` exception.
+        :exc:`~django.urls.Resolver404` exception.
 
 You can also use dictionary syntax on the response object to query the value
 of any settings in the HTTP headers. For example, you could determine the