Deprecated current_app in TemplateResponse and render(_to_response).

docs/internals/deprecation.txt

@@ -90,6 +90,14 @@ details on these changes.
 * The backwards compatibility alias ``django.template.loader.BaseLoader`` will
   be removed.
 
+* The ``current_app`` parameter for the following function and classes will be
+  removed:
+
+  * ``django.shortcuts.render()``
+  * ``django.template.Context()``
+  * ``django.template.RequestContext()``
+  * ``django.template.response.TemplateResponse()``
+
 * The ``dictionary`` and ``context_instance`` parameters for the following
   functions will be removed:
 

docs/ref/contrib/admin/index.txt

@@ -2628,11 +2628,16 @@ a pattern for your new view.
 .. note::
 
     Any view you render that uses the admin templates, or extends the base
-    admin template, should provide the ``current_app`` argument to
-    :class:`~django.template.RequestContext` or
-    :class:`~django.template.Context` when rendering the template.  It should
-    be set to either ``self.name`` if your view is on an ``AdminSite`` or
-    ``self.admin_site.name`` if your view is on a ``ModelAdmin``.
+    admin template, should set ``request.current_app`` before rendering the
+    template. It should be set to either ``self.name`` if your view is on an
+    ``AdminSite`` or ``self.admin_site.name`` if your view is on a
+    ``ModelAdmin``.
+
+    .. versionchanged:: 1.8
+
+       In previous versions of Django, you had to provide the ``current_app``
+       argument to :class:`~django.template.RequestContext` or
+       :class:`~django.template.Context` when rendering the template.
 
 .. _auth_password_reset:
 

docs/ref/template-response.txt

@@ -182,6 +182,11 @@ Methods
         :ref:`namespaced URL resolution strategy <topics-http-reversing-url-namespaces>`
         for more information.
 
+        .. deprecated:: 1.8
+
+           The ``current_app`` argument is deprecated. Instead you should set
+           ``request.current_app``.
+
     ``charset``
         The charset in which the response will be encoded. If not given it will
         be extracted from ``content_type``, and if that is unsuccessful, the

docs/releases/1.8.txt

@@ -1204,6 +1204,21 @@ to construct the "view on site" URL. This URL is now accessible using the
 sure to provide a default value for the ``form_class`` argument since it's
 now optional.
 
+``current_app`` argument of template-related APIs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following functions and classes will no longer accept a ``current_app``
+parameter to set an URL namespace in Django 2.0:
+
+* ``django.shortcuts.render()``
+* ``django.template.Context()``
+* ``django.template.RequestContext()``
+* ``django.template.response.TemplateResponse()``
+
+Set ``request.current_app`` instead, where ``request`` is the first argument
+to these functions or classes. If you're using a plain ``Context``, use a
+``RequestContext`` instead.
+
 ``dictionary`` and ``context_instance`` arguments of rendering functions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

docs/topics/http/shortcuts.txt

@@ -72,6 +72,11 @@ Optional arguments
     :ref:`namespaced URL resolution strategy <topics-http-reversing-url-namespaces>`
     for more information.
 
+    .. deprecated:: 1.8
+
+       The ``current_app`` argument is deprecated. Instead you should set
+       ``request.current_app``.
+
 .. versionchanged:: 1.7
 
    The ``dirs`` parameter was added.

docs/topics/http/urls.txt

@@ -633,10 +633,16 @@ 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 as an attribute on the template context - applications that
-   expect to have multiple deployments should set the ``current_app``
-   attribute on any :class:`~django.template.Context` or
-   :class:`~django.template.RequestContext` that is used to render a template.
+   specified as an attribute on the request. Applications that expect to
+   have multiple deployments should set the ``current_app`` attribute on
+   the ``request`` being processed.
+
+   .. versionchanged:: 1.8
+
+      In previous versions of Django, you had to set the ``current_app``
+      attribute on any :class:`~django.template.Context` or
+      :class:`~django.template.RequestContext` that is used to render a
+      template.
 
    The current application can also be specified manually as an argument
    to the :func:`~django.core.urlresolvers.reverse` function.
@@ -707,10 +713,10 @@ Using this setup, the following lookups are possible:
     {% url 'polls:index' %}
 
   Note that reversing in the template requires the ``current_app`` be added as
-  an attribute to the template context like this::
+  an attribute to the ``request`` like this::
 
     def render_to_response(self, context, **response_kwargs):
-        response_kwargs['current_app'] = self.request.resolver_match.namespace
+        self.request.current_app = self.request.resolver_match.namespace
         return super(DetailView, self).render_to_response(context, **response_kwargs)
 
 * If there is no current instance - say, if we were rendering a page