Supported multiple template engines in render_to_string.

Adjusted its API through a deprecation path according to the DEP.

3 files changed, 32 insertions, 4 deletions

diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
index 50ff5ce3b9..216aab9574 100644
--- a/docs/internals/deprecation.txt
+++ b/docs/internals/deprecation.txt
@@ -88,6 +88,11 @@ details on these changes.
 * The backwards compatibility alias ``django.template.loader.BaseLoader`` will
   be removed.
 
+* The ``dictionary`` and ``context_instance`` parameters for the following
+  functions will be removed:
+
+  * ``django.template.loader.render_to_string()``
+
 * The ``dirs`` parameter for the following functions will be removed:
 
   * ``django.template.loader.get_template()``
diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt
index c86b7873ae..f184544838 100644
--- a/docs/ref/templates/api.txt
+++ b/docs/ref/templates/api.txt
@@ -890,7 +890,7 @@ When :setting:`TEMPLATE_DEBUG` is ``True`` template objects will have an
 The ``render_to_string`` shortcut
 ===================================
 
-.. function:: loader.render_to_string(template_name, dictionary=None, context_instance=None)
+.. function:: loader.render_to_string(template_name, context=None, context_instance=None)
 
 To cut down on the repetitive nature of loading and rendering
 templates, Django provides a shortcut function which largely
@@ -906,16 +906,25 @@ The ``render_to_string`` shortcut takes one required argument --
 and render (or a list of template names, in which case Django will use
 the first template in the list that exists) -- and two optional arguments:
 
-dictionary
+``context``
     A dictionary to be used as variables and values for the
-    template's context. This can also be passed as the second
+    template's context. This should be passed as the second
     positional argument.
 
-context_instance
+    .. versionchanged:: 1.8
+
+       The ``context`` argument used to be called ``dictionary``. That name
+       is deprecated in Django 1.8 and will be removed in Django 2.0.
+
+``context_instance``
     An instance of :class:`~django.template.Context` or a subclass (e.g., an
     instance of :class:`~django.template.RequestContext`) to use as the
     template's context. This can also be passed as the third positional argument.
 
+    .. deprecated:: 1.8
+
+       The ``context_instance`` argument is deprecated. Simply use ``context``.
+
 See also the :func:`~django.shortcuts.render_to_response()` shortcut, which
 calls ``render_to_string`` and feeds the result into an :class:`~django.http.HttpResponse`
 suitable for returning directly from a view.
diff --git a/docs/releases/1.8.txt b/docs/releases/1.8.txt
index 8bf3659ba2..54ff4c605e 100644
--- a/docs/releases/1.8.txt
+++ b/docs/releases/1.8.txt
@@ -1198,6 +1198,20 @@ 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.
 
+``dictionary`` and ``context_instance`` arguments of rendering functions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following functions will no longer accept the ``dictionary`` and
+``context_instance`` parameters in Django 2.0:
+
+* ``django.template.loader.render_to_string()``
+
+Use the ``context`` parameter instead. When ``dictionary`` is passed as a
+positional argument, which is the most common idiom, no changes are needed.
+
+There is no replacement for ``context_instance``. All data must be passed to
+templates through the ``context`` dict.
+
 ``dirs`` argument of template-finding functions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~