summaryrefslogtreecommitdiff
path: root/docs/narr/renderers.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/narr/renderers.rst')
-rw-r--r--docs/narr/renderers.rst8
1 files changed, 3 insertions, 5 deletions
diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index 235dbaf83..4046c67fa 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -52,11 +52,9 @@ As we've seen, a view callable needn't always return a Response object.
Instead, it may return an arbitrary Python object, with the expectation that
a :term:`renderer` will convert that object into a response instance on your
behalf. Some renderers use a templating system; other renderers use object
-serialization techniques. Because renderers inject variable data into some
-output (otherwise a static Response object could be returned) the renderer
-must have some means of identifying the data and mapping its transformation
-into the desired output. Often, as the means of providing this mapping, the
-object supplied to the renderer is a Python dictionary.
+serialization techniques. In practice, renderers obtain application data
+values from Python dictionaries so, in practice, view callables which use
+renderers return Python dictionaries.
View configuration can vary the renderer associated with a view callable via
the ``renderer`` attribute. For example, this call to