More small fixes made reading the rest of the docs and the tutorials.

6 files changed, 44 insertions, 45 deletions

diff --git a/docs/narr/advconfig.rst b/docs/narr/advconfig.rst
index 5ee554284..3bd9c2a4e 100644
--- a/docs/narr/advconfig.rst
+++ b/docs/narr/advconfig.rst
@@ -86,9 +86,9 @@ that ends something like this:
        for action in resolveConflicts(self.actions):
      File "zope/configuration/config.py", line 1507, in resolveConflicts
        raise ConfigurationConflictError(conflicts)
-   zope.configuration.config.ConfigurationConflictError: 
+   zope.configuration.config.ConfigurationConflictError:
            Conflicting configuration actions
-     For: ('view', None, '', None, <InterfaceClass pyramid.interfaces.IView>, 
+     For: ('view', None, '', None, <InterfaceClass pyramid.interfaces.IView>,
            None, None, None, None, None, False, None, None, None)
     ('app.py', 14, '<module>', 'config.add_view(hello_world)')
     ('app.py', 17, '<module>', 'config.add_view(hello_world)')
@@ -291,7 +291,7 @@ These are the methods of the configurator which provide conflict detection:
 :meth:`~pyramid.config.Configurator.add_route`,
 :meth:`~pyramid.config.Configurator.add_renderer`,
 :meth:`~pyramid.config.Configurator.set_request_factory`,
-:meth:`~pyramid.config.Configurator.set_renderer_globals_factory`
+:meth:`~pyramid.config.Configurator.set_renderer_globals_factory`,
 :meth:`~pyramid.config.Configurator.set_locale_negotiator` and
 :meth:`~pyramid.config.Configurator.set_default_permission`.
 
@@ -425,7 +425,7 @@ For example:
 
    if __name__ == '__main__':
       config = Configurator()
-      config.add_directive('add_newrequest_subscriber', 
+      config.add_directive('add_newrequest_subscriber',
                            add_newrequest_subscriber)
 
 Once :meth:`~pyramid.config.Configurator.add_directive` is called, a user can
@@ -450,7 +450,7 @@ code in a package named ``pyramid_subscriberhelpers``:
    :linenos:
 
    def includeme(config)
-      config.add_directive('add_newrequest_subscriber', 
+      config.add_directive('add_newrequest_subscriber',
                            add_newrequest_subscriber)
 
 The user of the add-on package ``pyramid_subscriberhelpers`` would then be
diff --git a/docs/narr/environment.rst b/docs/narr/environment.rst
index e15f7810c..3b938c09c 100644
--- a/docs/narr/environment.rst
+++ b/docs/narr/environment.rst
@@ -13,7 +13,7 @@
    single: environment variables
    single: ini file settings
    single: PasteDeploy settings
-  
+
 .. _environment_chapter:
 
 Environment Variables and ``.ini`` File Settings
@@ -84,7 +84,7 @@ when this value is true.  See also :ref:`debug_authorization_section`.
 | ``PYRAMID_DEBUG_AUTHORIZATION`` |  ``debug_authorization``    |
 |                                 |                             |
 |                                 |                             |
-|                                 |                             | 
+|                                 |                             |
 +---------------------------------+-----------------------------+
 
 Debugging Not Found Errors
@@ -259,7 +259,7 @@ List of string filter names that will be applied to all Mako expressions.
 Mako Import
 +++++++++++
 
-String list of Python statements, typically individual “import” lines, which
+String list of Python statements, typically individual "import" lines, which
 will be placed into the module level preamble of all generated Python modules.
 
 
@@ -330,7 +330,7 @@ settings that do not start with ``debug_*`` such as
 ``reload_templates``.
 
 If you want to turn all ``reload`` settings (every setting that starts
-with ``reload_``). on in one fell swoop, you can use
+with ``reload_``) on in one fell swoop, you can use
 ``PYRAMID_RELOAD_ALL=1`` as an environment variable setting or you may use
 ``reload_all=true`` in the config file.  Note that this does not
 affect settings that do not start with ``reload_*`` such as
@@ -341,10 +341,10 @@ affect settings that do not start with ``reload_*`` such as
    most useful during development, where you may wish to augment or
    override the more permanent settings in the configuration file.
    This is useful because many of the reload and debug settings may
-   have performance or security (i.e., disclosure) implications 
+   have performance or security (i.e., disclosure) implications
    that make them undesirable in a production environment.
 
-.. index:: 
+.. index::
    single: reload_templates
    single: reload_assets
 
@@ -442,7 +442,7 @@ Here's how:
      registry = pyramid.threadlocal.get_current_registry()
      settings = registry.settings
      debug_frobnosticator = settings['debug_frobnosticator']
-   
 
-  
+
+
 
diff --git a/docs/narr/extending.rst b/docs/narr/extending.rst
index 9c96fd605..f62c7e6bb 100644
--- a/docs/narr/extending.rst
+++ b/docs/narr/extending.rst
@@ -120,7 +120,7 @@ are declarations made using the :meth:`pyramid.config.Configurator.add_view`
 method.  Assets are files that are
 accessed by :app:`Pyramid` using the :term:`pkg_resources` API such as static
 files and templates via a :term:`asset specification`.  Other directives and
-configurator methods also deal in routes, views, and assets.  For example,
+configurator methods also deal in routes, views, and assets.  For example, the
 ``add_handler`` directive of the ``pyramid_handlers`` package adds a single
 route, and some number of views.
 
@@ -163,7 +163,7 @@ views or routes which performs overrides.
    if __name__ == '__main__':
        config.scan('someotherpackage')
        config.commit()
-       config.add_view('mypackage.views.myview', name='myview'
+       config.add_view('mypackage.views.myview', name='myview')
 
 Once this is done, you should be able to extend or override the application
 like any other (see :ref:`extending_the_application`).
@@ -201,7 +201,7 @@ like this:
   application (e.g. ``python setup.py develop`` or ``python setup.py
   install``).
 
-- Change the ``main`` function in the new package's ``__init__py`` to include
+- Change the ``main`` function in the new package's ``__init__.py`` to include
   the original :app:`Pyramid` application's configuration functions via
   :meth:`pyramid.config.Configurator.include` statements or a :term:`scan`.
 
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index 7e3fe0a5c..be139ad74 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -84,7 +84,7 @@ The default forbidden response has a 403 status code and is very plain, but
 the view which generates it can be overridden as necessary.
 
 The :term:`forbidden view` callable is a view callable like any other.  The
-:term:`view configuration` which causes it to be a "not found" view consists
+:term:`view configuration` which causes it to be a "forbidden" view consists
 only of naming the :exc:`pyramid.exceptions.Forbidden` class as the
 ``context`` of the view configuration.
 
@@ -182,7 +182,7 @@ Adding Renderer Globals
 -----------------------
 
 Whenever :app:`Pyramid` handles a request to perform a rendering (after a
-view with a ``renderer=`` configuration attribute is invoked, or when the any
+view with a ``renderer=`` configuration attribute is invoked, or when any
 of the methods beginning with ``render`` within the :mod:`pyramid.renderers`
 module are called), *renderer globals* can be injected into the *system*
 values sent to the renderer.  By default, no renderer globals are injected,
@@ -199,7 +199,7 @@ callable object or a :term:`dotted Python name` representing such a callable.
    :linenos:
 
    def renderer_globals_factory(system):
-       return {'a':1}
+       return {'a': 1}
 
    config = Configurator(
             renderer_globals_factory=renderer_globals_factory)
@@ -220,7 +220,7 @@ already constructed a :term:`configurator` it can also be registered via the
    from pyramid.config import Configurator
 
    def renderer_globals_factory(system):
-       return {'a':1}
+       return {'a': 1}
 
    config = Configurator()
    config.set_renderer_globals_factory(renderer_globals_factory)
@@ -237,8 +237,8 @@ Using The Before Render Event
 -----------------------------
 
 Subscribers to the :class:`pyramid.events.BeforeRender` event may introspect
-the and modify the set of :term:`renderer globals` before they are passed to
-a :term:`renderer`.  This event object iself has a dictionary-like interface
+and modify the set of :term:`renderer globals` before they are passed to a
+:term:`renderer`.  This event object iself has a dictionary-like interface
 that can be used for this purpose.  For example:
 
 .. code-block:: python
@@ -484,7 +484,7 @@ resource by adding a registerAdapter call for
    from myapp.traversal import URLGenerator
    from myapp.resources import MyRoot
 
-   config.registry.registerAdapter(URLGenerator, (MyRoot, Interface), 
+   config.registry.registerAdapter(URLGenerator, (MyRoot, Interface),
                                    IContextURL)
 
 In the above example, the ``myapp.traversal.URLGenerator`` class will be used
@@ -531,7 +531,7 @@ Using a View Mapper
 
 The default calling conventions for view callables are documented in the
 :ref:`views_chapter` chapter.  You can change the way users define view
-callbles by employing a :term:`view mapper`.
+callables by employing a :term:`view mapper`.
 
 A view mapper is an object that accepts a set of keyword arguments and which
 returns a callable.  The returned callable is called with the :term:`view
@@ -645,24 +645,22 @@ follows:
    :linenos:
 
    import venusian
-   from pyramid.threadlocal import get_current_registry
    from mypackage.interfaces import IMyUtility
-    
+
    class registerFunction(object):
-        
+
        def __init__(self, path):
            self.path = path
 
        def register(self, scanner, name, wrapped):
            registry = scanner.config.registry
            registry.getUtility(IMyUtility).register(
-               self.path, wrapped
-               )
-        
+               self.path, wrapped)
+
        def __call__(self, wrapped):
            venusian.attach(wrapped, self.register)
            return wrapped
-    
+
 This decorator could then be used to register functions throughout
 your code:
 
@@ -681,16 +679,17 @@ performed, enabling you to set up the utility in advance:
 
    from paste.httpserver import serve
    from pyramid.config import Configurator
+   from mypackage.interfaces import IMyUtility
 
    class UtilityImplementation:
 
-       implements(ISomething)
+       implements(IMyUtility)
 
        def __init__(self):
           self.registrations = {}
 
-       def register(self,path,callable_):
-          self.registrations[path]=callable_
+       def register(self, path, callable_):
+          self.registrations[path] = callable_
 
    if __name__ == '__main__':
        config = Configurator()
diff --git a/docs/narr/i18n.rst b/docs/narr/i18n.rst
index e928c6efb..c21a19b5b 100644
--- a/docs/narr/i18n.rst
+++ b/docs/narr/i18n.rst
@@ -95,7 +95,7 @@ translations of the same msgid, in case they conflict.
    :linenos:
 
    from pyramid.i18n import TranslationString
-   ts = TranslationString('Add ${number}', mapping={'number':1}, 
+   ts = TranslationString('Add ${number}', mapping={'number':1},
                           domain='form')
 
 The above translation string named a domain of ``form``.  A
@@ -170,7 +170,7 @@ to:
    :linenos:
 
    from pyramid.i18n import TranslationString as _
-   ts = _('Add ${number}', msgid='add-number', mapping={'number':1}, 
+   ts = _('Add ${number}', msgid='add-number', mapping={'number':1},
           domain='pyramid')
 
 You can set up your own translation string factory much like the one
@@ -231,7 +231,7 @@ GNU gettext uses three types of files in the translation framework,
 
   A ``.pot`` file is created by a program which searches through your
   project's source code and which picks out every :term:`message
-  identifier` passed to one of the '``_()`` functions
+  identifier` passed to one of the ``_()`` functions
   (eg. :term:`translation string` constructions). The list of all
   message identifiers is placed into a ``.pot`` file, which serves as
   a template for creating ``.po`` files.
@@ -288,7 +288,7 @@ like so:
 .. code-block:: text
 
    C> cd \my\virtualenv
-   C> bin\easy_install Babel lingua
+   C> Scripts\easy_install Babel lingua
 
 .. index::
    single: Babel; message extractors
@@ -535,7 +535,7 @@ translation in a view component of an application might look like so:
    from pyramid.i18n import get_localizer
    from pyramid.i18n import TranslationString
 
-   ts = TranslationString('Add ${number}', mapping={'number':1}, 
+   ts = TranslationString('Add ${number}', mapping={'number':1},
                           domain='pyramid')
 
    def aview(request):
@@ -844,7 +844,7 @@ Then as a part of the code of a custom :term:`locale negotiator`:
 
 .. code-block:: python
    :linenos:
-    
+
    from pyramid.threadlocal import get_current_registry
    settings = get_current_registry().settings
    languages = settings['available_languages'].split()
@@ -897,7 +897,7 @@ application startup.  For example:
    :linenos:
 
    from pyramid.config import Configurator
-   config.add_translation_dirs('my.application:locale/', 
+   config.add_translation_dirs('my.application:locale/',
                                'another.application:locale/')
 
 A message catalog in a translation directory added via
diff --git a/docs/narr/zca.rst b/docs/narr/zca.rst
index 19c52d0c9..a99fd8b24 100644
--- a/docs/narr/zca.rst
+++ b/docs/narr/zca.rst
@@ -38,10 +38,10 @@ code is high.
 While the ZCA is an excellent tool with which to build a *framework*
 such as :app:`Pyramid`, it is not always the best tool with which
 to build an *application* due to the opacity of the ``zope.component``
-APIs.  Accordingly, :app:`Pyramid` tends to hide the the presence
-of the ZCA from application developers.  You needn't understand the
-ZCA to create a :app:`Pyramid` application; its use is effectively
-only a framework implementation detail.
+APIs.  Accordingly, :app:`Pyramid` tends to hide the presence of the
+ZCA from application developers.  You needn't understand the ZCA to
+create a :app:`Pyramid` application; its use is effectively only a
+framework implementation detail.
 
 However, developers who are already used to writing :term:`Zope`
 applications often still wish to use the ZCA while building a