Docs: Make statements more concreate regards renderers getting data from dictionaries.

2 files changed, 4 insertions, 6 deletions

diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 9a1ba190d..61b6ae316 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -878,7 +878,7 @@ This view callable function is handed a single piece of information: the
 :term:`request`.  The *request* is an instance of the :term:`WebOb`
 ``Request`` class representing the browser's request to our server.
 
-.. note:: Dictionaries (typically) provide values to :term:`template`s.
+.. note:: Dictionaries provide values to :term:`template`s.
 
 This view is configured to invoke a :term;`renderer` on a template.  The
 dictionary the view returns (on line 6) provides the value the renderer
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