change some slightly awkward wording

2 files changed, 24 insertions, 25 deletions

diff --git a/docs/tutorials/wiki2/basiclayout.rst b/docs/tutorials/wiki2/basiclayout.rst
index 6d6287126..0193afab4 100644
--- a/docs/tutorials/wiki2/basiclayout.rst
+++ b/docs/tutorials/wiki2/basiclayout.rst
@@ -132,11 +132,10 @@ Finally, ``main`` is finished configuring things, so it uses the
 View Declarations via ``views.py``
 ----------------------------------
 
-Arguably, the main function of a web framework is mapping each URL
-patterns, see :term:`route`, to code, see :term:`view callable`, that is 
-executed when the requested URL matches the corresponding :term:`route`. Our 
-application uses the :meth:`pyramid.view.view_config` decorator to perform 
-this mapping.
+The main function of a web framework is mapping each URL pattern to code (a
+:term:`view callable`) that is executed when the requested URL matches the
+corresponding :term:`route`. Our application uses the
+:meth:`pyramid.view.view_config` decorator to perform this mapping.
 
 Open ``tutorial/tutorial/views.py``.  It should already contain the following:
 
@@ -228,10 +227,10 @@ To give a simple example of a  model class, we define one named ``MyModel``:
 
 Our example model has an ``__init__`` method that takes two arguments
 (``name``, and ``value``).  It stores these values as ``self.name`` and
-``self.value`` within the ``__init__`` function itself.  The ``MyModel`` class 
-also has a ``__tablename__`` attribute.  This informs SQLAlchemy which table 
-to use to store the data representing instances of this class.
-
-That's about all there is to it with models, views, and initialization code in
-our stock application.
+``self.value`` on the instance created by the ``__init__`` function itself.
+The ``MyModel`` class also has a ``__tablename__`` attribute.  This informs
+SQLAlchemy which table to use to store the data representing instances of this
+class.
 
+That's about all there is to it regarding models, views, and initialization
+code in our stock application.
diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst
index 9894bcb08..53f8e569c 100644
--- a/docs/tutorials/wiki2/definingviews.rst
+++ b/docs/tutorials/wiki2/definingviews.rst
@@ -6,13 +6,13 @@ A :term:`view callable` in a :app:`Pyramid` application is typically a simple
 Python function that accepts a single parameter named :term:`request`.  A
 view callable is assumed to return a :term:`response` object.
 
-The request object has a dictionary as an attribute named ``matchdict``. 
-A ``matchdict`` maps the placeholders in the matching URL ``pattern`` to the substrings 
-of the :term:`request` ed URL. For instance, if a call to 
-:meth:`pyramid.config.Configurator.add_route` has the pattern 
-``{one}/{two}``, and a user visits ``http://example.com/foo/bar``, our pattern would be 
-matched and the ``matchdict`` would look like: ``{'one':'foo', 'two':'bar'}``
-
+The request object has a dictionary as an attribute named ``matchdict``.  A
+``matchdict`` maps the placeholders in the matching URL ``pattern`` to the
+substrings of the path in the :term:`request` URL. For instance, if a call to
+:meth:`pyramid.config.Configurator.add_route` has the pattern ``/{one}/{two}``,
+and a user visits ``http://example.com/foo/bar``, our pattern would be matched
+against ``/foo/bar`` and the ``matchdict`` would look like: ``{'one':'foo',
+'two':'bar'}``
 
 Declaring Dependencies in Our ``setup.py`` File
 ===============================================
@@ -145,13 +145,13 @@ As a result, the ``content`` variable is now a fully formed bit of HTML
 containing various view and add links for WikiWords based on the content of
 our current page object.
 
-We then generate an edit URL (because it's easier to do here than in the
-template), and we return a dictionary with a number of arguments.  The fact
-that ``view_page()`` returns a dictionary (as opposed to a :term:`response`
-object) is a cue to :app:`Pyramid` that it should try to use a :term:`renderer`
-associated with the view configuration to render a response.  In our case,
-the renderer used will be the ``templates/view.pt`` template, as indicated in 
-the ``@view_config`` decorator that is applied to ``view_page()``.
+We then generate an edit URL because it's easier to do here than in the
+template, and we return a dictionary with a number of arguments.  The fact that
+``view_page()`` returns a dictionary (as opposed to a :term:`response` object)
+is a cue to :app:`Pyramid` that it should try to use a :term:`renderer`
+associated with the view configuration to render a response.  In our case, the
+renderer used will be the ``templates/view.pt`` template, as indicated in the
+``@view_config`` decorator that is applied to ``view_page()``.
 
 The ``add_page`` view function
 ------------------------------