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

Thanks to Tim Graham for the review.

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)
 

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`).

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
 ==================

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

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:

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)

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):

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>`.

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

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):

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
 

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

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
 

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::

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,

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 ``"/"``.

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.

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.
 

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

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`).

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

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
 ~~~~~~~~~~~~~~~~~~~~~~~~

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

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`).

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

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

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

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`).

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

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

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`).
 

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

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.
 

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

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

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):
             ...

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

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')

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
 

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