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

Thanks to Tim Graham for the review.
This commit is contained in:
Marten Kenbeek 2015-12-30 16:51:16 +01:00 committed by Tim Graham
parent df3d5b1d73
commit 16411b8400
117 changed files with 961 additions and 922 deletions

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

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

View file

@ -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,

View file

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