- All references to Pyramid-the-application were changed from :mod:`pyramid`

  to :app:`Pyramid`.  A custom role setting was added to ``docs/conf.py`` to
  allow for this.  (internal)

30 files changed, 502 insertions, 502 deletions

diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst
index dc89b42cb..6a91cbf75 100644
--- a/docs/narr/configuration.rst
+++ b/docs/narr/configuration.rst
@@ -6,22 +6,22 @@
 Application Configuration 
 =========================
 
-Each deployment of an application written using :mod:`pyramid` implies a
+Each deployment of an application written using :app:`Pyramid` implies a
 specific *configuration* of the framework itself.  For example, an
 application which serves up MP3s for user consumption might plug code into
 the framework that manages songs, while an application that manages corporate
-data might plug in code that manages accounting information.  :mod:`pyramid`
+data might plug in code that manages accounting information.  :app:`Pyramid`
 refers to the way in which code is plugged in to it for a specific
 application as "configuration".
 
 Most people understand "configuration" as coarse settings that inform the
 high-level operation of a specific application deployment.  For instance,
 it's easy to think of the values implied by a ``.ini`` file parsed at
-application startup time as "configuration".  :mod:`pyramid` extends this
+application startup time as "configuration".  :app:`Pyramid` extends this
 pattern to application development, using the term "configuration" to express
 standardized ways that code gets plugged into a deployment of the framework
-itself.  When you plug code into the :mod:`pyramid` framework, you are
-"configuring" :mod:`pyramid` for the purpose of creating a particular
+itself.  When you plug code into the :app:`Pyramid` framework, you are
+"configuring" :app:`Pyramid` for the purpose of creating a particular
 application deployment.
 
 .. index::
@@ -32,7 +32,7 @@ application deployment.
 Imperative Configuration
 ------------------------
 
-Here's one of the simplest :mod:`pyramid` applications, configured
+Here's one of the simplest :app:`Pyramid` applications, configured
 imperatively:
 
 .. code-block:: python
@@ -77,7 +77,7 @@ An alternate mode of configuration lends more *locality of reference* to a
 configuration done in imperative code, because you may need to have two files
 open at once to see the "big picture": the file that represents the
 configuration, and the file that contains the implementation objects
-referenced by the configuration.  To avoid this, :mod:`pyramid` allows you to
+referenced by the configuration.  To avoid this, :app:`Pyramid` allows you to
 insert :term:`configuration decoration` statements very close to code that is
 referred to by the declaration itself.  For example:
 
@@ -93,7 +93,7 @@ referred to by the declaration itself.  For example:
 
 The mere existence of configuration decoration doesn't cause any
 configuration registration to be made.  Before they have any effect on
-the configuration of a :mod:`pyramid` application, a configuration
+the configuration of a :app:`Pyramid` application, a configuration
 decoration within application code must be found through a process
 known as a :term:`scan`.
 
@@ -101,7 +101,7 @@ The :class:`pyramid.view.view_config` decorator above adds an
 attribute to the ``hello`` function, making it available for a
 :term:`scan` to find it later.
 
-:mod:`pyramid` is willing to :term:`scan` a module or a package and
+:app:`Pyramid` is willing to :term:`scan` a module or a package and
 its subpackages for decorations when the
 :meth:`pyramid.configuration.Configurator.scan` method is invoked:
 scanning implies searching for configuration declarations in a package
@@ -155,7 +155,7 @@ Declarative Configuration
 -------------------------
 
 A third mode of configuration can be employed when you create a
-:mod:`pyramid` application named *declarative configuration*.  This mode uses
+:app:`Pyramid` application named *declarative configuration*.  This mode uses
 :term:`ZCML` to represent configuration statements rather than Python.  ZCML
 is often used when application extensibility is important.  Most of the
 examples in the narrative portion of this documentation concentrate on
diff --git a/docs/narr/contextfinding.rst b/docs/narr/contextfinding.rst
index cd504a571..c3fbe7f5a 100644
--- a/docs/narr/contextfinding.rst
+++ b/docs/narr/contextfinding.rst
@@ -11,24 +11,24 @@ framework must provide a mechanism to find and invoke code written by
 the application developer based on parameters present in the
 :term:`request`.
 
-:mod:`pyramid` uses two separate but cooperating subsystems to find
+:app:`Pyramid` uses two separate but cooperating subsystems to find
 and invoke code written by the application developer: :term:`context
 finding` and :term:`view lookup`.
 
-- A :mod:`pyramid` :term:`context finding` subsystem is given a
+- A :app:`Pyramid` :term:`context finding` subsystem is given a
   :term:`request`; it is responsible for finding a :term:`context`
   object and a :term:`view name` based on information present in the
   request.
 
 - Using the context and view name provided by :term:`context finding`,
-  the :mod:`pyramid` :term:`view lookup` subsystem is provided with
+  the :app:`Pyramid` :term:`view lookup` subsystem is provided with
   a :term:`request`, a :term:`context` and a :term:`view name`.  It is
   then responsible for finding and invoking a :term:`view callable`.
   A view callable is a specific bit of code written and registered by
   the application developer which receives the :term:`request` and
   which returns a :term:`response`.
 
-These two subsystems are used by :mod:`pyramid` serially:
+These two subsystems are used by :app:`Pyramid` serially:
 first, a :term:`context finding` subsystem does its job.  Then the
 result of context finding is passed to the :term:`view lookup`
 subsystem.  The view lookup system finds a :term:`view callable`
@@ -38,7 +38,7 @@ requesting user.
 
 .. sidebar::  What Good is A Context Finding Subsystem?
 
-   The :term:`URL dispatch` mode of :mod:`pyramid` as well as many
+   The :term:`URL dispatch` mode of :app:`Pyramid` as well as many
    other web frameworks such as :term:`Pylons` or :term:`Django`
    actually collapse the two steps of context finding and view lookup
    into a single step.  In these systems, a URL can map *directly* to
@@ -51,14 +51,14 @@ requesting user.
    that do not provide a notion of a context.
 
 There are two separate :term:`context finding` subsystems in
-:mod:`pyramid`: :term:`traversal` and :term:`URL dispatch`.  The
+:app:`Pyramid`: :term:`traversal` and :term:`URL dispatch`.  The
 subsystems are documented within this chapter.  They can be used
 separately or they can be combined.  Three chapters which follow
 describe :term:`context finding`: :ref:`traversal_chapter`,
 :ref:`urldispatch_chapter` and :ref:`hybrid_chapter`.
 
 There is only one :term:`view lookup` subsystem present in
-:mod:`pyramid`.  Where appropriate, within this chapter, we
+:app:`Pyramid`.  Where appropriate, within this chapter, we
 describe how view lookup interacts with context finding.  One chapter
 which follows describes :term:`view lookup`: :ref:`views_chapter`.
 
@@ -113,6 +113,6 @@ in terms of traversing that graph.  However, when you have a
 hierarchical data store, using traversal can provide significant
 advantages over using URL-based dispatch.
 
-Since :mod:`pyramid` provides support for both approaches, you can
+Since :app:`Pyramid` provides support for both approaches, you can
 use either exclusively or combine them as you see fit.
 
diff --git a/docs/narr/declarative.rst b/docs/narr/declarative.rst
index 232f42751..48a3ea134 100644
--- a/docs/narr/declarative.rst
+++ b/docs/narr/declarative.rst
@@ -9,7 +9,7 @@ configuration mode in which a developer cedes the least amount of control to
 the framework; it's "imperative" because you express the configuration
 directly in Python code, and you have the full power of Python at your
 disposal as you issue configuration statements.  However, another mode of
-configuration exists within :mod:`pyramid`, which often provides better
+configuration exists within :app:`Pyramid`, which often provides better
 extensibility and configuration conflict detection.
 
 A complete listing of ZCML directives is available within
@@ -26,12 +26,12 @@ ZCML from :ref:`extending_chapter`.
 Declarative Configuration
 -------------------------
 
-A :mod:`pyramid` application can be configured "declaratively", if so
+A :app:`Pyramid` application can be configured "declaratively", if so
 desired.  Declarative configuration relies on *declarations* made external to
 the code in a configuration file format named :term:`ZCML` (Zope
 Configuration Markup Language), an XML dialect.
 
-A :mod:`pyramid` application configured declaratively requires not
+A :app:`Pyramid` application configured declaratively requires not
 one, but two files: a Python file and a :term:`ZCML` file.
 
 In a file named ``helloworld.py``:
@@ -138,7 +138,7 @@ effectively a "macro" which calls the
 :meth:`pyramid.configuration.Configurator.add_view` method on your
 behalf.
 
-The ``<view>`` tag is an example of a :mod:`pyramid` declaration
+The ``<view>`` tag is an example of a :app:`Pyramid` declaration
 tag.  Other such tags include ``<route>`` and ``<scan>``.  Each of
 these tags is effectively a "macro" which calls methods of a
 :class:`pyramid.configuration.Configurator` object on your behalf.
@@ -203,7 +203,7 @@ Hello World, Goodbye World (Declarative)
 ----------------------------------------
 
 Another almost entirely equivalent mode of application configuration
-exists named *declarative* configuration.  :mod:`pyramid` can be
+exists named *declarative* configuration.  :app:`Pyramid` can be
 configured for the same "hello world" application "declaratively", if
 so desired.
 
@@ -338,7 +338,7 @@ The ``configure.zcml`` ZCML file contains this bit of XML:
     </configure>
 
 Because :term:`ZCML` is XML, and because XML requires a single root
-tag for each document, every ZCML file used by :mod:`pyramid` must
+tag for each document, every ZCML file used by :app:`Pyramid` must
 contain a ``configure`` container directive, which acts as the root
 XML tag.  It is a "container" directive because its only job is to
 contain other directives.
@@ -355,7 +355,7 @@ The ``configure.zcml`` ZCML file contains this bit of XML within the
 
    <include package="pyramid.includes" />
 
-This self-closing tag instructs :mod:`pyramid` to load a ZCML file
+This self-closing tag instructs :app:`Pyramid` to load a ZCML file
 from the Python package with the :term:`dotted Python name`
 ``pyramid.includes``, as specified by its ``package`` attribute.
 This particular ``<include>`` declaration is required because it
@@ -406,7 +406,7 @@ The ``configure.zcml`` ZCML file contains these bits of XML *after* the
      view="helloworld.goodbye_world"
      />
 
-These ``<view>`` declaration tags direct :mod:`pyramid` to create
+These ``<view>`` declaration tags direct :app:`Pyramid` to create
 two :term:`view configuration` registrations.  The first ``<view>``
 tag has an attribute (the attribute is also named ``view``), which
 points at a :term:`dotted Python name`, referencing the
@@ -472,7 +472,7 @@ completely equivalent:
        view="helloworld.hello_world"
        />
 
-We've now configured a :mod:`pyramid` helloworld application
+We've now configured a :app:`Pyramid` helloworld application
 declaratively.  More information about this mode of configuration is
 available in :ref:`declarative_configuration` and within
 :ref:`zcml_reference`.
@@ -529,9 +529,9 @@ A combination of imperative configuration, declarative configuration
 via ZCML and scanning can be used to configure any application.  They
 are not mutually exclusive.
 
-The :mod:`pyramid` authors often recommend using mostly declarative
+The :app:`Pyramid` authors often recommend using mostly declarative
 configuration, because it's the more traditional form of configuration
-used in :mod:`pyramid` applications, it can be overridden and
+used in :app:`Pyramid` applications, it can be overridden and
 extended by third party deployers, and there are more examples for it
 "in the wild".
 
@@ -625,7 +625,7 @@ attribute:
        name="hello.html"
        />
 
-This indicates that when :mod:`pyramid` identifies that the
+This indicates that when :app:`Pyramid` identifies that the
 :term:`view name` is ``hello.html`` and the context is of any type,
 the ``.views.hello_world`` view callable will be invoked.
 
@@ -698,7 +698,7 @@ will resolve to a package-qualified resource such as
 
 Here's an example of a ``static`` ZCML directive that will serve files
 up under the ``/static`` URL from the ``/var/www/static`` directory of
-the computer which runs the :mod:`pyramid` application using an
+the computer which runs the :app:`Pyramid` application using an
 absolute path.
 
 .. code-block:: xml
@@ -821,7 +821,7 @@ and an instance of the class
 :class:`pyramid.authorization.ACLAuthorizationPolicy` to be
 injected as the :term:`authorization policy` used by this application.
 
-:mod:`pyramid` ships with a number of authorization and
+:app:`Pyramid` ships with a number of authorization and
 authentication policy ZCML directives that should prove useful.  See
 :ref:`authentication_policies_directives_section` and
 :ref:`authorization_policies_directives_section` for more information.
@@ -835,7 +835,7 @@ Built-In Authentication Policy ZCML Directives
 ----------------------------------------------
 
 Instead of configuring an authentication policy and authorization
-policy imperatively, :mod:`pyramid` ships with a few "pre-chewed"
+policy imperatively, :app:`Pyramid` ships with a few "pre-chewed"
 authentication policy ZCML directives that you can make use of within
 your application.
 
@@ -937,7 +937,7 @@ See :ref:`aclauthorizationpolicy_directive` for detailed information.
 Adding and Overriding Renderers via ZCML
 ----------------------------------------
 
-New templating systems and serializers can be associated with :mod:`pyramid`
+New templating systems and serializers can be associated with :app:`Pyramid`
 renderer names.  To this end, configuration declarations can be made which
 override an existing :term:`renderer factory` and which add a new renderer
 factory.
@@ -1041,7 +1041,7 @@ renderer factory, use:
       name=".zpt"
       factory="pyramid.chameleon_zpt.renderer_factory"/>
 
-After you do this, :mod:`pyramid` will treat templates ending in
+After you do this, :app:`Pyramid` will treat templates ending in
 both the ``.pt`` and ``.zpt`` filename extensions as Chameleon ZPT
 templates.
 
diff --git a/docs/narr/environment.rst b/docs/narr/environment.rst
index 83de12863..2aa4064cd 100644
--- a/docs/narr/environment.rst
+++ b/docs/narr/environment.rst
@@ -19,7 +19,7 @@
 Environment Variables and ``.ini`` File Settings
 ================================================
 
-:mod:`pyramid` behavior can be configured through a combination of
+:app:`Pyramid` behavior can be configured through a combination of
 operating system environment variables and ``.ini`` configuration file
 application section settings.  The meaning of the environment
 variables and the configuration file settings overlap.
@@ -32,7 +32,7 @@ variables and the configuration file settings overlap.
 The term "configuration file setting name" refers to a key in the
 ``.ini`` configuration for your application.  The configuration file
 setting names documented in this chapter are reserved for
-:mod:`pyramid` use.  You should not use them to indicate
+:app:`Pyramid` use.  You should not use them to indicate
 application-specific configuration settings.
 
 Reloading Templates
@@ -206,7 +206,7 @@ Examples
 
 Let's presume your configuration file is named ``MyProject.ini``, and
 there is a section representing your application named ``[app:main]``
-within the file that represents your :mod:`pyramid` application.
+within the file that represents your :app:`Pyramid` application.
 The configuration file settings documented in the above "Config File
 Setting Name" column would go in the ``[app:main]`` section.  Here's
 an example of such a section:
@@ -220,14 +220,14 @@ an example of such a section:
 
 You can also use environment variables to accomplish the same purpose
 for settings documented as such.  For example, you might start your
-:mod:`pyramid` application using the following command line:
+:app:`Pyramid` application using the following command line:
 
 .. code-block:: python
 
   $ BFG_DEBUG_AUTHORIZATION=1 BFG_RELOAD_TEMPLATES=1 bin/paster serve \
          MyProject.ini
 
-If you started your application this way, your :mod:`pyramid`
+If you started your application this way, your :app:`Pyramid`
 application would behave in the same manner as if you had placed the
 respective settings in the ``[app:main]`` section of your
 application's ``.ini`` file.
@@ -255,24 +255,24 @@ Understanding the Distinction Between ``reload_templates`` and ``reload_resource
 
 The difference between ``reload_resources`` and ``reload_templates``
 is a bit subtle.  Templates are themselves also treated by
-:mod:`pyramid` as :term:`pkg_resources` resource files (along with
+:app:`Pyramid` as :term:`pkg_resources` resource files (along with
 static files and other resources), so the distinction can be
 confusing.  It's helpful to read :ref:`overriding_resources_section`
 for some context about resources in general.
 
-When ``reload_templates`` is true, :mod:`pyramid` takes advantage
+When ``reload_templates`` is true, :app:`Pyramid` takes advantage
 of the underlying templating systems' ability to check for file
 modifications to an individual template file.  When
 ``reload_templates`` is true but ``reload_resources`` is *not* true,
 the template filename returned by pkg_resources is cached by
-:mod:`pyramid` on the first request.  Subsequent requests for the
+:app:`Pyramid` on the first request.  Subsequent requests for the
 same template file will return a cached template filename.  The
 underlying templating system checks for modifications to this
 particular file for every request.  Setting ``reload_templates`` to
 ``True`` doesn't affect performance dramatically (although it should
 still not be used in production because it has some effect).
 
-However, when ``reload_resources`` is true, :mod:`pyramid` will not
+However, when ``reload_resources`` is true, :app:`Pyramid` will not
 cache the template filename, meaning you can see the effect of
 changing the content of an overridden resource directory for templates
 without restarting the server after every change.  Subsequent requests
diff --git a/docs/narr/events.rst b/docs/narr/events.rst
index 703b7bb88..1edc2c5b0 100644
--- a/docs/narr/events.rst
+++ b/docs/narr/events.rst
@@ -11,14 +11,14 @@
 Using Events
 =============
 
-An *event* is an object broadcast by the :mod:`pyramid` framework
+An *event* is an object broadcast by the :app:`Pyramid` framework
 at interesting points during the lifetime of an application.  You
-don't need to use events in order to create most :mod:`pyramid`
+don't need to use events in order to create most :app:`Pyramid`
 applications, but they can be useful when you want to perform slightly
 advanced operations.  For example, subscribing to an event can allow
 you to run some code as the result of every new request.
 
-Events in :mod:`pyramid` are always broadcast by the framework.
+Events in :app:`Pyramid` are always broadcast by the framework.
 However, they only become useful when you register a *subscriber*.  A
 subscriber is a function that accepts a single argument named `event`:
 
@@ -86,7 +86,7 @@ function found via a :term:`scan`.
    :ref:`zcml_event_listener`.
 
 Either of the above registration examples implies that every time the
-:mod:`pyramid` framework emits an event object that supplies an
+:app:`Pyramid` framework emits an event object that supplies an
 :class:`pyramid.events.NewRequest` interface, the ``mysubscriber`` function
 will be called with an *event* object.
 
@@ -102,7 +102,7 @@ The return value of a subscriber function is ignored.  Subscribers to
 the same event type are not guaranteed to be called in any particular
 order relative to each other.
 
-All the concrete :mod:`pyramid` event types are documented in the
+All the concrete :app:`Pyramid` event types are documented in the
 :ref:`events_module` API documentation.
 
 An Example
diff --git a/docs/narr/extending.rst b/docs/narr/extending.rst
index 17ab370ea..49de50722 100644
--- a/docs/narr/extending.rst
+++ b/docs/narr/extending.rst
@@ -1,12 +1,12 @@
 .. _extending_chapter:
 
-Extending An Existing :mod:`pyramid` Application
+Extending An Existing :app:`Pyramid` Application
 ===================================================
 
-If the developer of a :mod:`pyramid` application has obeyed certain
+If the developer of a :app:`Pyramid` application has obeyed certain
 constraints while building that application, a third party should be
 able to change its behavior without needing to modify its source code.
-The behavior of a :mod:`pyramid` application that obeys certain
+The behavior of a :app:`Pyramid` application that obeys certain
 constraints can be *overridden* or *extended* without modification.
 
 .. index::
@@ -16,11 +16,11 @@ Rules for Building An Extensible Application
 --------------------------------------------
 
 There's only one rule you need to obey if you want to build a
-maximally extensible :mod:`pyramid` application: you should not use
+maximally extensible :app:`Pyramid` application: you should not use
 any :term:`configuration decoration` or :term:`imperative
 configuration`. This means the application developer should avoid
 relying on :term:`configuration decoration` meant to be detected via
-a :term:`scan`, and you mustn't configure your :mod:`pyramid`
+a :term:`scan`, and you mustn't configure your :app:`Pyramid`
 application *imperatively* by using any code which configures the
 application through methods of the :term:`Configurator` (except for
 the :meth:`pyramid.configuration.Configurator.load_zcml` method).
@@ -36,11 +36,11 @@ Fundamental Plugpoints
 ~~~~~~~~~~~~~~~~~~~~~~
 
 The fundamental "plug points" of an application developed using
-:mod:`pyramid` are *routes*, *views*, and *resources*.  Routes are
+:app:`Pyramid` are *routes*, *views*, and *resources*.  Routes are
 declarations made using the ZCML ``<route>`` directive.  Views are
 declarations made using the ZCML ``<view>`` directive (or the
 ``@view_config`` decorator).  Resources are files that are accessed by
-:mod:`pyramid` using the :term:`pkg_resources` API such as static
+:app:`Pyramid` using the :term:`pkg_resources` API such as static
 files and templates.
 
 .. index::
@@ -88,7 +88,7 @@ and/or imperative code.
 Extending an Application Which Possesses Configuration Decorators Or Which Does Configuration Imperatively
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you've inherited a :mod:`pyramid` application which uses
+If you've inherited a :app:`Pyramid` application which uses
 :class:`pyramid.view.view_config` decorators or which performs
 configuration imperatively, one of two things may be true:
 
@@ -132,7 +132,7 @@ The general pattern for extending an existing application looks
 something like this:
 
 - Create a new Python package.  The easiest way to do this is to
-  create a new :mod:`pyramid` application using the "paster"
+  create a new :app:`Pyramid` application using the "paster"
   template mechanism.  See :ref:`creating_a_project` for more
   information.
 
@@ -141,7 +141,7 @@ something like this:
   setup.py install``).
 
 - Change the ``configure.zcml`` in the new package to include the
-  original :mod:`pyramid` application's ``configure.zcml`` via an
+  original :app:`Pyramid` application's ``configure.zcml`` via an
   include statement, e.g.  ``<include package="theoriginalapp"/>``.
   Alternately, if the original application writer anticipated
   overriding some things and not others, instead of including the
diff --git a/docs/narr/firstapp.rst b/docs/narr/firstapp.rst
index f1bba6e89..bc21bf29f 100644
--- a/docs/narr/firstapp.rst
+++ b/docs/narr/firstapp.rst
@@ -1,9 +1,9 @@
 .. _firstapp_chapter:
 
-Creating Your First :mod:`pyramid` Application
+Creating Your First :app:`Pyramid` Application
 =================================================
 
-We will walk through the creation of a tiny :mod:`pyramid`
+We will walk through the creation of a tiny :app:`Pyramid`
 application in this chapter.  After we're finished creating it, we'll
 explain in more detail how the application works.
 
@@ -20,7 +20,7 @@ explain in more detail how the application works.
 Hello World, Goodbye World
 --------------------------
 
-Here's one of the very simplest :mod:`pyramid` applications,
+Here's one of the very simplest :app:`Pyramid` applications,
 configured imperatively:
 
 .. code-block:: python
@@ -46,7 +46,7 @@ configured imperatively:
        serve(app, host='0.0.0.0')
 
 When this code is inserted into a Python script named ``helloworld.py`` and
-executed by a Python interpreter which has the :mod:`pyramid` software
+executed by a Python interpreter which has the :app:`Pyramid` software
 installed, an HTTP server is started on TCP port 8080:
 
 .. code-block:: bash
@@ -76,17 +76,17 @@ The above script defines the following set of imports:
 
 The script imports the ``Configurator`` class from the
 ``pyramid.configuration`` module.  This class is used to configure
-:mod:`pyramid` for a particular application.  An instance of this class
-provides methods which help configure various parts of :mod:`pyramid` for a
+:app:`Pyramid` for a particular application.  An instance of this class
+provides methods which help configure various parts of :app:`Pyramid` for a
 given application deployment.
 
 The script uses the :class:`pyramid.response.Response` class later in the
 script to create a :term:`response` object.
 
-Like many other Python web frameworks, :mod:`pyramid` uses the :term:`WSGI`
+Like many other Python web frameworks, :app:`Pyramid` uses the :term:`WSGI`
 protocol to connect an application and a web server together.  The
 :mod:`paste.httpserver` server is used in this example as a WSGI server for
-convenience, as the ``paste`` package is a dependency of :mod:`pyramid` itself.
+convenience, as the ``paste`` package is a dependency of :app:`Pyramid` itself.
 
 View Callable Declarations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -110,7 +110,7 @@ The ``goodbye_world`` function returns a response instance with the
 body ``Goodbye world!``.
 
 Each of these functions is known as a :term:`view callable`.  View
-callables in a :mod:`pyramid` application accept a single argument,
+callables in a :app:`Pyramid` application accept a single argument,
 ``request`` and are expected to return a :term:`response` object.  A
 view callable doesn't need to be a function; it can be represented via
 another type of object, like a class or an instance, but for our
@@ -118,7 +118,7 @@ purposes here, a function serves us well.
 
 A view callable is always called with a :term:`request` object.  A
 request object is a representation of an HTTP request sent to
-:mod:`pyramid` via the active :term:`WSGI` server.
+:app:`Pyramid` via the active :term:`WSGI` server.
 
 A view callable is required to return a :term:`response` object because a
 response object has all the information necessary to formulate an actual HTTP
@@ -186,7 +186,7 @@ execution.
 The ``config = Configurator()`` line above creates an instance of the
 :class:`pyramid.configuration.Configurator` class.  The resulting
 ``config`` object represents an API which the script uses to configure
-this particular :mod:`pyramid` application.  Methods called on the
+this particular :app:`Pyramid` application.  Methods called on the
 Configurator will cause registrations to be made in a
 :term:`application registry` associated with the application.
 
@@ -243,7 +243,7 @@ argument passed is the ``hello_world`` function.  This line calls
 ``add_view`` with a *default* value for the :term:`predicate`
 argument, named ``name``.  The ``name`` predicate defaults to a value
 equalling the empty string (``''``).  This means that we're
-instructing :mod:`pyramid` to invoke the ``hello_world`` view
+instructing :app:`Pyramid` to invoke the ``hello_world`` view
 callable when the :term:`view name` is the empty string.  We'll learn
 in later chapters what a :term:`view name` is, and under which
 circumstances a request will have a view name that is the empty
@@ -268,17 +268,17 @@ keyword argument to the ``add_view`` method narrows the set of
 circumstances which would cause the view configuration's callable to
 be invoked.  In general, a greater number of predicates supplied along
 with a view configuration will more strictly limit the applicability
-of its associated view callable.  When :mod:`pyramid` processes a
+of its associated view callable.  When :app:`Pyramid` processes a
 request, however, the view callable with the *most specific* view
 configuration (the view configuration that matches the most specific
 set of predicates) is always invoked.
 
-In this application, :mod:`pyramid` chooses the most specific view
+In this application, :app:`Pyramid` chooses the most specific view
 callable based only on view :term:`predicate` applicability.  The
 ordering of calls to
 :meth:`pyramid.configuration.Configurator.add_view` is never very
 important.  We can register ``goodbye_world`` first and
-``hello_world`` second; :mod:`pyramid` will still give us the most
+``hello_world`` second; :app:`Pyramid` will still give us the most
 specific callable when a request is dispatched to it.
 
 Ending Configuration
@@ -328,8 +328,8 @@ Python applications.  We don't discuss :term:`WSGI` in any depth
 within this book, however, you can learn more about it by visiting
 `wsgi.org <http://wsgi.org>`_.
 
-The :mod:`pyramid` application object, in particular, is an
-instance of a class representing a :mod:`pyramid` :term:`router`.
+The :app:`Pyramid` application object, in particular, is an
+instance of a class representing a :app:`Pyramid` :term:`router`.
 It has a reference to the :term:`application registry` which resulted
 from method calls to the configurator used to configure it.  The
 :term:`router` consults the registry to obey the policy choices made
@@ -365,7 +365,7 @@ Conclusion
 ~~~~~~~~~~
 
 Our hello world application is one of the simplest possible
-:mod:`pyramid` applications, configured "imperatively".  We can see
+:app:`Pyramid` applications, configured "imperatively".  We can see
 that it's configured imperatively because the full power of Python is
 available to us as we perform configuration tasks.
 
diff --git a/docs/narr/handlers.rst b/docs/narr/handlers.rst
index dcb199bbc..b8e7b5d9b 100644
--- a/docs/narr/handlers.rst
+++ b/docs/narr/handlers.rst
@@ -3,7 +3,7 @@
 View Handlers
 =============
 
-Along with normal view callables, :mod:`pyramid` provides the concept of a
+Along with normal view callables, :app:`Pyramid` provides the concept of a
 :term:`view handler`.  Using a view handler instead of a plain :term:`view
 callable` makes it unnecessary to call
 :meth:`pyramid.configuration.Configurator.add_route` (and/or
@@ -19,7 +19,7 @@ predicate` to control which method of the handler is called.
    :term:`url dispatch`.  The concept of a view handler is analogous to a
    "controller" in Pylons 1.0.
 
-The view handler class is initialized by :mod:`pyramid` in the same manner as
+The view handler class is initialized by :app:`Pyramid` in the same manner as
 a view class.  Its ``__init__`` is called with a request object (see
 :ref:`class_as_view`) when a request enters the system which corresponds with
 a view handler registration made during configuration. A method of the view
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index f8d662447..b2d30cae4 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -3,7 +3,7 @@
 Using Hooks
 ===========
 
-"Hooks" can be used to influence the behavior of the :mod:`pyramid`
+"Hooks" can be used to influence the behavior of the :app:`Pyramid`
 framework in various ways.
 
 .. index::
@@ -14,7 +14,7 @@ framework in various ways.
 Changing the Not Found View
 ---------------------------
 
-When :mod:`pyramid` can't map a URL to view code, it invokes a
+When :app:`Pyramid` can't map a URL to view code, it invokes a
 :term:`not found view`, which is a :term:`view callable`. A default
 notfound view exists.  The default not found view can be overridden
 through application configuration.  This override can be done via
@@ -101,7 +101,7 @@ callable:
 Changing the Forbidden View
 ---------------------------
 
-When :mod:`pyramid` can't authorize execution of a view based on
+When :app:`Pyramid` can't authorize execution of a view based on
 the :term:`authorization policy` in use, it invokes a :term:`forbidden
 view`.  The default forbidden response has a 401 status code and is
 very plain, but the view which generates it can be overridden as
@@ -187,7 +187,7 @@ Here's some sample code that implements a minimal forbidden view:
 Changing the Traverser
 ----------------------
 
-The default :term:`traversal` algorithm that :mod:`pyramid` uses is
+The default :term:`traversal` algorithm that :app:`Pyramid` uses is
 explained in :ref:`traversal_algorithm`.  Though it is rarely
 necessary, this default algorithm can be swapped out selectively for a
 different traversal pattern via configuration.
@@ -256,10 +256,10 @@ traverser would be used.  For example:
       />
 
 If the above stanza was added to a ``configure.zcml`` file,
-:mod:`pyramid` would use the ``myapp.traversal.Traverser`` only
+:app:`Pyramid` would use the ``myapp.traversal.Traverser`` only
 when the application :term:`root factory` returned an instance of the
 ``myapp.models.MyRoot`` object.  Otherwise it would use the default
-:mod:`pyramid` traverser to do traversal.
+:app:`Pyramid` traverser to do traversal.
 
 .. index::
    single: url generator
@@ -327,13 +327,13 @@ the :term:`Pylons` GitHub Pyramid repository.
 Changing the Request Factory
 ----------------------------
 
-Whenever :mod:`pyramid` handles a :term:`WSGI` request, it creates
+Whenever :app:`Pyramid` handles a :term:`WSGI` request, it creates
 a :term:`request` object based on the WSGI environment it has been
 passed.  By default, an instance of the
 :class:`pyramid.request.Request` class is created to represent the
 request object.
 
-The class (aka "factory") that :mod:`pyramid` uses to create a
+The class (aka "factory") that :app:`Pyramid` uses to create a
 request object instance can be changed by passing a
 ``request_factory`` argument to the constructor of the
 :term:`configurator`.  This argument can be either a callable or a
@@ -385,7 +385,7 @@ method:
 Adding Renderer Globals
 -----------------------
 
-Whenever :mod:`pyramid` handles a request to perform a rendering
+Whenever :app:`Pyramid` handles a request to perform a rendering
 (after a view with a ``renderer=`` configuration attribute is invoked,
 or when the any of the methods beginning with ``render`` within the
 :mod:`pyramid.renderers` module are called), *renderer globals* can
@@ -395,7 +395,7 @@ values (such as ``request``, ``context``, and ``renderer_name``) are
 the only values present in the system dictionary passed to every
 renderer.
 
-A callback that :mod:`pyramid` will call every time a renderer is
+A callback that :app:`Pyramid` will call every time a renderer is
 invoked can be added by passing a ``renderer_globals_factory``
 argument to the constructor of the :term:`configurator`.  This
 callback can either be a callable object or a :term:`dotted Python
@@ -492,7 +492,7 @@ renderer global values exists in :ref:`adding_renderer_globals`.
 Using Response Callbacks
 ------------------------
 
-Unlike many other web frameworks, :mod:`pyramid` does not eagerly
+Unlike many other web frameworks, :app:`Pyramid` does not eagerly
 create a global response object.  Adding a :term:`response callback`
 allows an application to register an action to be performed against a
 response object once it is created, usually in order to mutate it.
@@ -524,7 +524,7 @@ Response callbacks are called in the order they're added
 (first-to-most-recently-added).  All response callbacks are called *after*
 the :class:`pyramid.events.NewResponse` event is sent.  Errors raised by
 response callbacks are not handled specially.  They will be propagated to the
-caller of the :mod:`pyramid` router application.
+caller of the :app:`Pyramid` router application.
 
 A response callback has a lifetime of a *single* request.  If you want a
 response callback to happen as the result of *every* request, you must
@@ -537,7 +537,7 @@ Using Finished Callbacks
 ------------------------
 
 A :term:`finished callback` is a function that will be called
-unconditionally by the :mod:`pyramid` :term:`router` at the very
+unconditionally by the :app:`Pyramid` :term:`router` at the very
 end of request processing.  A finished callback can be used to perform
 an action at the end of a request unconditionally.
 
@@ -583,7 +583,7 @@ enters a response callback will be an exception object instead of its
 default value of ``None``.
 
 Errors raised by finished callbacks are not handled specially.  They
-will be propagated to the caller of the :mod:`pyramid` router
+will be propagated to the caller of the :app:`Pyramid` router
 application.
 
 A finished callback has a lifetime of a *single* request.  If you want a
@@ -599,16 +599,16 @@ Registering Configuration Decorators
 Decorators such as :class:`pyramid.view.view_config` don't change the
 behavior of the functions or classes they're decorating.  Instead,
 when a :term:`scan` is performed, a modified version of the function
-or class is registered with :mod:`pyramid`.
+or class is registered with :app:`Pyramid`.
 
 You may wish to have your own decorators that offer such
 behaviour. This is possible by using the :term:`Venusian` package in
-the same way that it is used by :mod:`pyramid`.
+the same way that it is used by :app:`Pyramid`.
 
 By way of example, let's suppose you want to write a decorator that
 registers the function it wraps with a :term:`Zope Component
 Architecture` "utility" within the :term:`application registry`
-provided by :mod:`pyramid`. The application registry and the
+provided by :app:`Pyramid`. The application registry and the
 utility inside the registry is likely only to be available once your
 application's configuration is at least partially completed. A normal
 decorator would fail as it would be executed before the configuration
diff --git a/docs/narr/hybrid.rst b/docs/narr/hybrid.rst
index 24ae63059..61ac68d5d 100644
--- a/docs/narr/hybrid.rst
+++ b/docs/narr/hybrid.rst
@@ -3,11 +3,11 @@
 Combining Traversal and URL Dispatch
 ====================================
 
-When you write most :mod:`pyramid` applications, you'll be using
+When you write most :app:`Pyramid` applications, you'll be using
 one or the other of two available :term:`context finding` subsystems:
 traversal or URL dispatch.  However, to solve a limited set of
 problems, it's useful to use *both* traversal and URL dispatch
-together within the same application.  :mod:`pyramid` makes this
+together within the same application.  :app:`Pyramid` makes this
 possible via *hybrid* applications.
 
 .. warning::
@@ -24,7 +24,7 @@ A Review of Non-Hybrid Applications
 -----------------------------------
 
 When used according to the tutorials in its documentation
-:mod:`pyramid` is a "dual-mode" framework: the tutorials explain
+:app:`Pyramid` is a "dual-mode" framework: the tutorials explain
 how to create an application in terms of using either :term:`url
 dispatch` *or* :term:`traversal`.  This chapter details how you might
 combine these two dispatch mechanisms, but we'll review how they work
@@ -79,7 +79,7 @@ Hybrid Applications
 -------------------
 
 Either traversal or url dispatch alone can be used to create a
-:mod:`pyramid` application.  However, it is also possible to
+:app:`Pyramid` application.  However, it is also possible to
 combine the concepts of traversal and url dispatch when building an
 application: the result is a hybrid application.  In a hybrid
 application, traversal is performed *after* a particular route has
@@ -205,7 +205,7 @@ instead of invariably invoking a specific view callable named directly within
 the matched route's configuration.
 
 Because the pattern of the above route ends with ``*traverse``, when this
-route configuration is matched during a request, :mod:`pyramid`
+route configuration is matched during a request, :app:`Pyramid`
 will attempt to use :term:`traversal` against the :term:`root` object
 implied by the :term:`root factory` implied by the route's
 configuration.  Once :term:`traversal` has found a :term:`context`,
@@ -277,7 +277,7 @@ returned from the root factory.  In the above example, the
 If the URL that matched a route with the pattern ``:foo/:bar/*traverse``,
 is ``http://example.com/one/two/a/b/c``, the traversal path used
 against the root object will be ``a/b/c``.  As a result,
-:mod:`pyramid` will attempt to traverse through the edges ``a``,
+:app:`Pyramid` will attempt to traverse through the edges ``a``,
 ``b``, and ``c``, beginning at the root object.
 
 In our above example, this particular set of traversal steps will mean
diff --git a/docs/narr/i18n.rst b/docs/narr/i18n.rst
index a7b952019..703883fb2 100644
--- a/docs/narr/i18n.rst
+++ b/docs/narr/i18n.rst
@@ -15,7 +15,7 @@ one language or cultural context.  :term:`Localization` (l10n) is the
 process of displaying the user interface of an internationalized
 application in a *particular* language or cultural context.
 
-:mod:`pyramid` offers internationalization and localization
+:app:`Pyramid` offers internationalization and localization
 subsystems that can be used to translate the text of buttons, error
 messages and other software- and template-defined values into the
 native language of a user of your application.
@@ -35,7 +35,7 @@ text values into the languages used by your application's users.  This
 markup creates a :term:`translation string`.  A translation string is
 an object that behaves mostly like a normal Unicode object, except that
 it also carries around extra information related to its job as part of
-the :mod:`pyramid` translation machinery.
+the :app:`Pyramid` translation machinery.
 
 Using The ``TranslationString`` Class
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -207,7 +207,7 @@ method.
 Working With ``gettext`` Translation Files
 ------------------------------------------
 
-The basis of :mod:`pyramid` translation services is
+The basis of :app:`Pyramid` translation services is
 GNU :term:`gettext`. Once your application source code files and templates
 are marked up with translation markers, you can work on translations
 by creating various kinds of gettext files.
@@ -215,7 +215,7 @@ by creating various kinds of gettext files.
 .. note::
 
    The steps a developer must take to work with :term:`gettext`
-   :term:`message catalog` files within a :mod:`pyramid`
+   :term:`message catalog` files within a :app:`Pyramid`
    application are very similar to the steps a :term:`Pylons`
    developer must take to do the same.  See the `Pylons
    internationalization documentation
@@ -246,7 +246,7 @@ GNU gettext uses three types of files in the translation framework,
   makes the localized program run faster.
 
 The tool for working with :term:`gettext` translation files related to
-a :mod:`pyramid` application is :term:`Babel`.
+a :app:`Pyramid` application is :term:`Babel`.
 
 .. index::
    single: Babel
@@ -259,13 +259,13 @@ Installing Babel
 In order for the commands related to working with ``gettext``
 translation files to work properly, you will need to have
 :term:`Babel` installed into the same environment in which
-:mod:`pyramid` is installed.
+:app:`Pyramid` is installed.
 
 Installation on UNIX
 ++++++++++++++++++++
 
 If the :term:`virtualenv` into which you've installed your
-:mod:`pyramid` application lives in ``/my/virtualenv``, you can
+:app:`Pyramid` application lives in ``/my/virtualenv``, you can
 install Babel like so:
 
 .. code-block:: bash
@@ -277,7 +277,7 @@ Installation on Windows
 +++++++++++++++++++++++
 
 If the :term:`virtualenv` into which you've installed your
-:mod:`pyramid` application lives in ``C:\my\virtualenv``, you can
+:app:`Pyramid` application lives in ``C:\my\virtualenv``, you can
 install Babel like so:
 
 .. code-block:: bash
@@ -333,7 +333,7 @@ Extracting Messages from Code and Templates
 Once :term:`Babel` is installed and your application's ``setup.py``
 file has the correct message extractor references, you may extract a
 message catalog template from the code and :term:`Chameleon` templates
-which reside in your :mod:`pyramid` application.  You run a
+which reside in your :app:`Pyramid` application.  You run a
 ``setup.py`` command to extract the messages:
 
 .. code-block:: bash
@@ -353,11 +353,11 @@ The name ``myapplication`` above in the filename ``myapplication.pot``
 denotes the :term:`translation domain` of the translations that must
 be performed to localize your application.  By default, the
 translation domain is the :term:`project` name of your
-:mod:`pyramid` application.
+:app:`Pyramid` application.
 
 To change the translation domain of the extracted messages in your
 project, edit the ``setup.cfg`` file of your application, The default
-``setup.cfg`` file of a Paster-generated :mod:`pyramid` application
+``setup.cfg`` file of a Paster-generated :app:`Pyramid` application
 has stanzas in it that look something like the following:
 
 .. code-block:: ini
@@ -436,7 +436,7 @@ Once the file is there, it can be worked on by a human translator.
 One tool which may help with this is `Poedit
 <http://www.poedit.net/>`_.
 
-Note that :mod:`pyramid` itself ignores the existence of all
+Note that :app:`Pyramid` itself ignores the existence of all
 ``.po`` files.  For a running application to have translations
 available, a ``.mo`` file must exist.  See
 :ref:`compiling_message_catalog`.
@@ -477,7 +477,7 @@ translations, compile ``.po`` files to ``.mo`` files::
 This will create a ``.mo`` file for each ``.po`` file in your
 application.  As long as the :term:`translation directory` in which
 the ``.mo`` file ends up in is configured into your application, these
-translations will be available to :mod:`pyramid`.
+translations will be available to :app:`Pyramid`.
 
 .. index::
    single: localizer
@@ -645,7 +645,7 @@ to obtaining a locale name by calling the
 Performing Date Formatting and Currency Formatting
 --------------------------------------------------
 
-:mod:`pyramid` does not itself perform date and currency formatting
+:app:`Pyramid` does not itself perform date and currency formatting
 for different locales.  However, :term:`Babel` can help you do this
 via the :class:`babel.core.Locale` class.  The `Babel documentation
 for this class
@@ -655,7 +655,7 @@ related locale operations.  See :ref:`installing_babel` for
 information about how to install Babel.
 
 The :class:`babel.core.Locale` class requires a :term:`locale name` as
-an argument to its constructor. You can use :mod:`pyramid` APIs to
+an argument to its constructor. You can use :app:`Pyramid` APIs to
 obtain the locale name for a request to pass to the
 :class:`babel.core.Locale` constructor; see
 :ref:`obtaining_the_locale_name`.  For example:
@@ -712,20 +712,20 @@ through translation before being rendered:
 .. 1.2.3
 
 The features represented by attributes of the ``i18n`` namespace of
-Chameleon will also consult the :mod:`pyramid` translations.
+Chameleon will also consult the :app:`Pyramid` translations.
 See
 `http://chameleon.repoze.org/docs/latest/i18n.html#the-i18n-namespace
 <http://chameleon.repoze.org/docs/latest/i18n.html#the-i18n-namespace>`_.
 
 .. note::
 
-   Unlike when Chameleon is used outside of :mod:`pyramid`, when it
-   is used *within* :mod:`pyramid`, it does not support use of the
+   Unlike when Chameleon is used outside of :app:`Pyramid`, when it
+   is used *within* :app:`Pyramid`, it does not support use of the
    ``zope.i18n`` translation framework.  Applications which use
-   :mod:`pyramid` should use the features documented in this
+   :app:`Pyramid` should use the features documented in this
    chapter rather than ``zope.i18n``.
 
-Third party :mod:`pyramid` template renderers might not provide
+Third party :app:`Pyramid` template renderers might not provide
 this support out of the box and may need special code to do an
 equivalent.  For those, you can always use the more manual translation
 facility described in :ref:`performing_a_translation`.
@@ -739,7 +739,7 @@ facility described in :ref:`performing_a_translation`.
 Localization-Related Deployment Settings
 ----------------------------------------
 
-A :mod:`pyramid` application will have a ``default_locale_name``
+A :app:`Pyramid` application will have a ``default_locale_name``
 setting.  This value represents the :term:`default locale name` used
 when the :term:`locale negotiator` returns ``None``.  Pass it to the
 :mod:`pyramid.configuration.Configurator` constructor at startup
@@ -767,7 +767,7 @@ application's Paster ``.ini`` file:
 If this value is not supplied via the Configurator constructor or via
 a Paste config file, it will default to ``en``.
 
-If this setting is supplied within the :mod:`pyramid` application
+If this setting is supplied within the :app:`Pyramid` application
 ``.ini`` file, it will be available as a settings key:
 
 .. code-block:: python
@@ -784,7 +784,7 @@ Other systems provide an API that returns the set of "available
 languages" as indicated by the union of all languages in all
 translation directories on disk at the time of the call to the API.
 
-It is by design that :mod:`pyramid` doesn't supply such an API.
+It is by design that :app:`Pyramid` doesn't supply such an API.
 Instead, the application itself is responsible for knowing the "available
 languages".  The rationale is this: any particular application
 deployment must always know which languages it should be translatable
@@ -838,7 +838,7 @@ languages" configuration scheme as necessary.
 Activating Translation
 ----------------------
 
-By default, a :mod:`pyramid` application performs no translation.
+By default, a :app:`Pyramid` application performs no translation.
 To turn translation on, you must:
 
 - add at least one :term:`translation directory` to your application.
@@ -851,7 +851,7 @@ Adding a Translation Directory
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 :term:`gettext` is the underlying machinery behind the
-:mod:`pyramid` translation machinery.  A translation directory is a
+:app:`Pyramid` translation machinery.  A translation directory is a
 directory organized to be useful to :term:`gettext`.  A translation
 directory usually includes a listing of language directories, each of
 which itself includes an ``LC_MESSAGES`` directory.  Each
@@ -862,7 +862,7 @@ to provide translations to your application.
 Adding a :term:`translation directory` registers all of its
 constituent :term:`message catalog` files (all of the ``.mo`` files
 found within all ``LC_MESSAGES`` directories within each locale
-directory in the translation directory) within your :mod:`pyramid`
+directory in the translation directory) within your :app:`Pyramid`
 application to be available to use for translation services.
 
 You can add a translation directory imperatively by using the
@@ -893,7 +893,7 @@ Setting the Locale
 
 When the *default locale negotiator* (see
 :ref:`default_locale_negotiator`) is in use, you can inform
-:mod:`pyramid` of the current locale name by doing any of these
+:app:`Pyramid` of the current locale name by doing any of these
 things before any translations need to be performed:
 
 - Set the ``_LOCALE_`` attribute of the request to a valid locale name
@@ -985,7 +985,7 @@ Here's an implementation of a simple locale negotiator:
         return locale_name
 
 If a locale negotiator returns ``None``, it signifies to
-:mod:`pyramid` that the default application locale name should be
+:app:`Pyramid` that the default application locale name should be
 used.
 
 You may add your newly created locale negotiator to your application's
diff --git a/docs/narr/install.rst b/docs/narr/install.rst
index 3a1703801..c753b7298 100644
--- a/docs/narr/install.rst
+++ b/docs/narr/install.rst
@@ -1,6 +1,6 @@
 .. _installing_chapter:
 
-Installing :mod:`pyramid`
+Installing :app:`Pyramid`
 ============================
 
 .. index::
@@ -10,22 +10,22 @@ Before You Install
 ------------------
 
 You will need `Python <http://python.org>`_ version 2.4 or better to
-run :mod:`pyramid`.  
+run :app:`Pyramid`.  
 
 .. sidebar:: Python Versions
 
-    As of this writing, :mod:`pyramid` has been tested under Python
+    As of this writing, :app:`Pyramid` has been tested under Python
     2.4.6, Python 2.5.4 and Python 2.6.2, and Python 2.7.  To ensure
-    backwards compatibility, development of :mod:`pyramid` is
+    backwards compatibility, development of :app:`Pyramid` is
     currently done primarily under Python 2.4 and Python 2.5.
-    :mod:`pyramid` does not run under any version of Python before
+    :app:`Pyramid` does not run under any version of Python before
     2.4, and does not yet run under Python 3.X.
 
-:mod:`pyramid` is known to run on all popular Unix-like systems
+:app:`Pyramid` is known to run on all popular Unix-like systems
 such as Linux, MacOS X, and FreeBSD as well as on Windows platforms.
 It is also known to run on Google's App Engine and :term:`Jython`.
 
-:mod:`pyramid` installation does not require the compilation of any
+:app:`Pyramid` installation does not require the compilation of any
 C code, so you need only a Python interpreter that meets the
 requirements mentioned.
 
@@ -60,7 +60,7 @@ Source Compile Method
 
 It's useful to use a Python interpreter that *isn't* the "system"
 Python interpreter to develop your software.  The authors of
-:mod:`pyramid` tend not to use the system Python for development
+:app:`Pyramid` tend not to use the system Python for development
 purposes; always a self-compiled one.  Compiling Python is usually
 easy, and often the "system" Python is compiled with options that
 aren't optimal for web development.
@@ -126,20 +126,20 @@ extensions <http://sourceforge.net/projects/pywin32/files/>`_.
 
 .. _installing_unix:
 
-Installing :mod:`pyramid` on a UNIX System
+Installing :app:`Pyramid` on a UNIX System
 ---------------------------------------------
 
-It is best practice to install :mod:`pyramid` into a "virtual"
+It is best practice to install :app:`Pyramid` into a "virtual"
 Python environment in order to obtain isolation from any "system"
 packages you've got installed in your Python version.  This can be
 done by using the :term:`virtualenv` package.  Using a virtualenv will
-also prevent :mod:`pyramid` from globally installing versions of
+also prevent :app:`Pyramid` from globally installing versions of
 packages that are not compatible with your system Python.
 
-To set up a virtualenv in which to install :mod:`pyramid`, first
+To set up a virtualenv in which to install :app:`Pyramid`, first
 ensure that :term:`setuptools` is installed.  Invoke ``import
 setuptools`` within the Python interpreter you'd like to run
-:mod:`pyramid` under:
+:app:`Pyramid` under:
 
 .. code-block:: text
 
@@ -225,8 +225,8 @@ following:
 .. warning:: Using ``--no-site-packages`` when generating your
    virtualenv is *very important*. This flag provides the necessary
    isolation for running the set of packages required by
-   :mod:`pyramid`.  If you do not specify ``--no-site-packages``,
-   it's possible that :mod:`pyramid` will not install properly into
+   :app:`Pyramid`.  If you do not specify ``--no-site-packages``,
+   it's possible that :app:`Pyramid` will not install properly into
    the virtualenv, or, even if it does, may not run properly,
    depending on the packages you've already got installed into your
    Python's "main" site-packages dir.
@@ -238,11 +238,11 @@ following:
 You should perform any following commands that mention a "bin"
 directory from within the ``env`` virtualenv dir.
 
-Installing :mod:`pyramid` Into the Virtual Python Environment
+Installing :app:`Pyramid` Into the Virtual Python Environment
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 After you've got your ``env`` virtualenv installed, you may install
-:mod:`pyramid` itself using the following commands from within the
+:app:`Pyramid` itself using the following commands from within the
 virtualenv (``env``) directory:
 
 .. code-block:: text
@@ -257,7 +257,7 @@ downloads and installs a number of dependencies.
 
 .. _installing_windows:
 
-Installing :mod:`pyramid` on a Windows System
+Installing :app:`Pyramid` on a Windows System
 -------------------------------------------------
 
 #. Install, or find `Python 2.6
@@ -300,7 +300,7 @@ Installing :mod:`pyramid` on a Windows System
    environment wired to use the virtualenv.
 
 #. Use ``easy_install`` pointed at the "current" index to get
-   :mod:`pyramid` and its direct dependencies installed:
+   :app:`Pyramid` and its direct dependencies installed:
 
    .. code-block:: text
 
@@ -309,29 +309,29 @@ Installing :mod:`pyramid` on a Windows System
 .. index::
    single: installing on Google App Engine
 
-Installing :mod:`pyramid` on Google App Engine
+Installing :app:`Pyramid` on Google App Engine
 -------------------------------------------------
 
 :ref:`appengine_tutorial` documents the steps required to install a
-:mod:`pyramid` application on Google App Engine.
+:app:`Pyramid` application on Google App Engine.
 
-Installing :mod:`pyramid` on Jython
+Installing :app:`Pyramid` on Jython
 --------------------------------------
 
-:mod:`pyramid` is known to work under :term:`Jython` version 2.5.1.
+:app:`Pyramid` is known to work under :term:`Jython` version 2.5.1.
 Install :term:`Jython`, and then follow the installation steps for
-:mod:`pyramid` on your platform described in one of the sections
+:app:`Pyramid` on your platform described in one of the sections
 entitled :ref:`installing_unix` or :ref:`installing_windows` above,
 replacing the ``python`` command with ``jython`` as necessary.  The
 steps are exactly the same except you should use the ``jython``
 command name instead of the ``python`` command name.
 
-One caveat exists to using :mod:`pyramid` under Jython: the
+One caveat exists to using :app:`Pyramid` under Jython: the
 :term:`Chameleon` templating engine, which is the default templating
-engine for :mod:`pyramid` does not work on Jython.
+engine for :app:`Pyramid` does not work on Jython.
 
 The ``pyramid_jinja2`` distribution provides templating for
-:mod:`pyramid` using the :term:`Jinja2` templating system.  You may
+:app:`Pyramid` using the :term:`Jinja2` templating system.  You may
 install it like so using the ``easy_install`` command for Jython:
 
 .. code-block:: python
@@ -339,7 +339,7 @@ install it like so using the ``easy_install`` command for Jython:
    $ easy_install pyramid_jinja2
 
 Once this is done, you can use this command to get started with a
-:mod:`pyramid` sample application that uses the Jinja2 templating
+:app:`Pyramid` sample application that uses the Jinja2 templating
 engine:
 
 .. code-block:: python
@@ -352,10 +352,10 @@ about the ``paster create`` command.
 What Gets Installed
 -------------------
 
-When you ``easy_install`` :mod:`pyramid`, various Zope libraries,
+When you ``easy_install`` :app:`Pyramid`, various Zope libraries,
 various Chameleon libraries, WebOb, Paste, PasteScript, and
 PasteDeploy libraries are installed.
 
 Additionally, as chronicled in :ref:`project_narr`, PasteScript (aka
 *paster*) templates will be registered that make it easy to start a
-new :mod:`pyramid` project.
+new :app:`Pyramid` project.
diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst
index 01dd91e26..725d32725 100644
--- a/docs/narr/introduction.rst
+++ b/docs/narr/introduction.rst
@@ -6,7 +6,7 @@
    single: frameworks vs. libraries
    single: framework
 
-:mod:`pyramid` Introduction
+:app:`Pyramid` Introduction
 ==============================
 
 If they are judged only by differences in user interface, most web
@@ -17,14 +17,14 @@ page served by another application might be a listing of songs.  These
 applications probably won't serve the same set of customers.  However,
 although they're not very similar on the surface, both a
 ledger-serving application and a song-serving application can be
-written using :mod:`pyramid`.
+written using :app:`Pyramid`.
 
-:mod:`pyramid` is a very general open source Python web
+:app:`Pyramid` is a very general open source Python web
 *framework*.  As a framework, its primary job is to make it easier for
 a developer to create an arbitrary web application.  The type of
 application being created isn't really important; it could be a
 spreadsheet, a corporate intranet, or an "oh-so-Web-2.0" social
-networking platform.  :mod:`pyramid` is general enough that it can
+networking platform.  :app:`Pyramid` is general enough that it can
 be used in a wide variety of circumstances.
 
 .. sidebar:: Frameworks vs. Libraries
@@ -44,53 +44,53 @@ be used in a wide variety of circumstances.
    own via a set of libraries if the framework provides a set of
    facilities that fits your application requirements.
 
-The first release of the predecessor to :mod:`pyramid` (named
+The first release of the predecessor to :app:`Pyramid` (named
 :mod:`repoze.bfg`) was made in July of 2008.  Since its first release,
 we've tried to ensure that it maintains the following attributes:
 
 Simplicity
-  :mod:`pyramid` attempts to be a *"pay only for what you eat"*
+  :app:`Pyramid` attempts to be a *"pay only for what you eat"*
   framework which delivers results even if you have only partial
   knowledge.  Other frameworks may expect you to understand many
   concepts and technologies fully before you can be truly productive.
-  :mod:`pyramid` doesn't force you to use any particular technology
+  :app:`Pyramid` doesn't force you to use any particular technology
   to produce an application, and we try to keep the core set of
   concepts you need to understand to a minimum.
 
 A Sense of Fun
-  Developing a :mod:`pyramid` application should not feel
+  Developing a :app:`Pyramid` application should not feel
   "enterprisey".  We like to keep things down-to-earth.
 
 Minimalism
-  :mod:`pyramid` provides only the very basics: *URL to code
+  :app:`Pyramid` provides only the very basics: *URL to code
   mapping*, *templating*, *security*, and *resources*.  There is not
   much more to the framework than these pieces: you are expected to
   provide the rest.
 
 Documentation
-  Because :mod:`pyramid` is minimal, it's relatively easy to keep
+  Because :app:`Pyramid` is minimal, it's relatively easy to keep
   its documentation up-to-date, which is helpful to bring new
   developers up to speed.  It's our goal that nothing remain
-  undocumented about :mod:`pyramid`.
+  undocumented about :app:`Pyramid`.
 
 Speed
-  :mod:`pyramid` is faster than many other popular Python web
+  :app:`Pyramid` is faster than many other popular Python web
   frameworks for common tasks such as templating and simple response
   generation.  The "hardware is cheap" mantra has its limits when
   you're responsible for managing a great many machines: the fewer you
   need, the less pain you'll have.
 
 Familiarity
-  The :mod:`pyramid` framework is a canonization of practices that
+  The :app:`Pyramid` framework is a canonization of practices that
   "fit the brains" of its authors.
 
 Trustability
-  :mod:`pyramid` is developed conservatively and tested
+  :app:`Pyramid` is developed conservatively and tested
   exhaustively.  *If it ain't tested, it's broke.* Every release of
-  :mod:`pyramid` has 100% statement coverage via unit tests.
+  :app:`Pyramid` has 100% statement coverage via unit tests.
 
 Openness
-  Like :term:`Python`, the :mod:`pyramid` software is distributed
+  Like :term:`Python`, the :app:`Pyramid` software is distributed
   under a `permissive open source license
   <http://repoze.org/license.html>`_.
 
@@ -102,10 +102,10 @@ Openness
 What Is The Pylons Project?
 ---------------------------
 
-:mod:`pyramid` is a member of the collection of software published under the
+:app:`Pyramid` is a member of the collection of software published under the
 Pylons Project.  :Pylons software is written by a loose-knit community of
 contributors.  The `Pylons Project website <http://docs.pylonshq.com>`_
-includes details about how :mod:`pyramid` relates to the Pylons Project.
+includes details about how :app:`Pyramid` relates to the Pylons Project.
 
 .. index::
    single: pyramid and other frameworks
@@ -114,30 +114,30 @@ includes details about how :mod:`pyramid` relates to the Pylons Project.
    single: Django
    single: MVC
 
-:mod:`pyramid` and Other Web Frameworks
+:app:`Pyramid` and Other Web Frameworks
 ------------------------------------------
 
-Until the end of 2010, :mod:`pyramid` was known as :mod:`repoze.bfg`; it was
-merged into the Pylons project as :mod:`pyramid` in November of that year.
+Until the end of 2010, :app:`Pyramid` was known as :mod:`repoze.bfg`; it was
+merged into the Pylons project as :app:`Pyramid` in November of that year.
 
-:mod:`pyramid` was inspired by :term:`Zope`, :term:`Pylons` (version
-1.0) and :term:`Django`.  As a result, :mod:`pyramid` borrows several
+:app:`Pyramid` was inspired by :term:`Zope`, :term:`Pylons` (version
+1.0) and :term:`Django`.  As a result, :app:`Pyramid` borrows several
 concepts and features from each, combining them into a unique web
 framework.
 
-Many features of :mod:`pyramid` trace their origins back to
-:term:`Zope`.  Like Zope applications, :mod:`pyramid` applications
+Many features of :app:`Pyramid` trace their origins back to
+:term:`Zope`.  Like Zope applications, :app:`Pyramid` applications
 can be configured via a set of declarative configuration files.  Like
-Zope applications, :mod:`pyramid` applications can be easily
+Zope applications, :app:`Pyramid` applications can be easily
 extended: if you obey certain constraints, the application you produce
 can be reused, modified, re-integrated, or extended by third-party
 developers without forking the original application.  The concepts of
-:term:`traversal` and declarative security in :mod:`pyramid` were
+:term:`traversal` and declarative security in :app:`Pyramid` were
 pioneered first in Zope.
 
-The :mod:`pyramid` concept of :term:`URL dispatch` is inspired by the
+The :app:`Pyramid` concept of :term:`URL dispatch` is inspired by the
 :term:`Routes` system used by :term:`Pylons` version 1.0.  Like Pylons
-version 1.0, :mod:`pyramid` is mostly policy-free.  It makes no
+version 1.0, :app:`Pyramid` is mostly policy-free.  It makes no
 assertions about which database you should use, and its built-in
 templating facilities are included only for convenience.  In essence,
 it only supplies a mechanism to map URLs to :term:`view` code, along
@@ -145,44 +145,44 @@ with a set of conventions for calling those views.  You are free to
 use third-party components that fit your needs in your applications.
 
 The concepts of :term:`view` and :term:`model` are used by
-:mod:`pyramid` mostly as they would be by Django.
-:mod:`pyramid` has a documentation culture more like Django's than
+:app:`Pyramid` mostly as they would be by Django.
+:app:`Pyramid` has a documentation culture more like Django's than
 like Zope's.
 
 Like :term:`Pylons` version 1.0, but unlike :term:`Zope`, a
-:mod:`pyramid` application developer may use completely imperative
+:app:`Pyramid` application developer may use completely imperative
 code to perform common framework configuration tasks such as adding a
 view or a route.  In Zope, :term:`ZCML` is typically required for
 similar purposes.  In :term:`Grok`, a Zope-based web framework,
 :term:`decorator` objects and class-level declarations are used for
-this purpose.  :mod:`pyramid` supports :term:`ZCML` and
+this purpose.  :app:`Pyramid` supports :term:`ZCML` and
 decorator-based configuration, but does not require either. See
 :ref:`configuration_narr` for more information.
 
 Also unlike :term:`Zope` and unlike other "full-stack" frameworks such
-as :term:`Django`, :mod:`pyramid` makes no assumptions about which
+as :term:`Django`, :app:`Pyramid` makes no assumptions about which
 persistence mechanisms you should use to build an application.  Zope
-applications are typically reliant on :term:`ZODB`; :mod:`pyramid`
+applications are typically reliant on :term:`ZODB`; :app:`Pyramid`
 allows you to build :term:`ZODB` applications, but it has no reliance
 on the ZODB software.  Likewise, :term:`Django` tends to assume that
 you want to store your application's data in a relational database.
-:mod:`pyramid` makes no such assumption; it allows you to use a
+:app:`Pyramid` makes no such assumption; it allows you to use a
 relational database but doesn't encourage or discourage the decision.
 
 Other Python web frameworks advertise themselves as members of a class
 of web frameworks named `model-view-controller
 <http://en.wikipedia.org/wiki/Model–view–controller>`_ frameworks.
 Insofar as this term has been claimed to represent a class of web
-frameworks, :mod:`pyramid` also generally fits into this class.
+frameworks, :app:`Pyramid` also generally fits into this class.
 
-.. sidebar:: You Say :mod:`pyramid` is MVC, But Where's The Controller?
+.. sidebar:: You Say :app:`Pyramid` is MVC, But Where's The Controller?
 
-   The :mod:`pyramid` authors believe that the MVC pattern just
-   doesn't really fit the web very well. In a :mod:`pyramid`
+   The :app:`Pyramid` authors believe that the MVC pattern just
+   doesn't really fit the web very well. In a :app:`Pyramid`
    application, there are models, which store data, and views, which
    present the data stored in models.  However, no facility provided
    by the framework actually maps to the concept of a "controller".
-   So :mod:`pyramid` is actually an "MV" framework rather than an
+   So :app:`Pyramid` is actually an "MV" framework rather than an
    "MVC" framework.  "MVC", however, is close enough as a general
    classification moniker for purposes of comparison with other web
    frameworks.
diff --git a/docs/narr/models.rst b/docs/narr/models.rst
index f2b3182a5..f8488cc80 100644
--- a/docs/narr/models.rst
+++ b/docs/narr/models.rst
@@ -3,9 +3,9 @@ Models
 
 A :term:`model` class is typically a simple Python class defined in a
 module.  References to these classes and instances of such classes are
-omnipresent in :mod:`pyramid`:
+omnipresent in :app:`Pyramid`:
 
-- Model instances make up the graph that :mod:`pyramid` is
+- Model instances make up the graph that :app:`Pyramid` is
   willing to walk over when :term:`traversal` is used.
 
 - The ``context`` and ``containment`` arguments to
@@ -31,16 +31,16 @@ mutating that data.
    different notion of the definition of a "model".  When using the API
    of common ORM packages, its conception of "model" is almost
    certainly not the same conception of "model" used by
-   :mod:`pyramid`.  In particular, it can be unnatural to think of
-   :mod:`pyramid` model objects as "models" if you develop your
+   :app:`Pyramid`.  In particular, it can be unnatural to think of
+   :app:`Pyramid` model objects as "models" if you develop your
    application using :term:`traversal` and a relational database.  When
    you develop such applications, the object graph *might* be composed
    completely of "model" objects (as defined by the ORM) but it also
-   might not be.  The things that :mod:`pyramid` refers to as
+   might not be.  The things that :app:`Pyramid` refers to as
    "models" in such an application may instead just be stand-ins that
    perform a query and generate some wrapper *for* an ORM "model" or
    set of ORM models.  This naming overlap is slightly unfortunate.
-   However, many :mod:`pyramid` applications (especially ones which
+   However, many :app:`Pyramid` applications (especially ones which
    use :term:`ZODB`) do indeed traverse a graph full of literal model
    nodes.  Each node in the graph is a separate persistent object that
    is stored within a database.  This was the use case considered when
@@ -200,10 +200,10 @@ Defining a Graph of Model Instances for Traversal
 -------------------------------------------------
 
 When :term:`traversal` is used (as opposed to a purely :term:`url
-dispatch` based application), :mod:`pyramid` expects to be able to
+dispatch` based application), :app:`Pyramid` expects to be able to
 traverse a graph composed of model instances.  Traversal begins at a
 root model, and descends into the graph recursively via each found
-model's ``__getitem__`` method.  :mod:`pyramid` imposes the
+model's ``__getitem__`` method.  :app:`Pyramid` imposes the
 following policy on model instance nodes in the graph:
 
 - Nodes which contain other nodes (aka "container" nodes) must supply
@@ -238,13 +238,13 @@ Location-Aware Model Instances
   :mod:`repoze.bfg.traversalwrapper` package (available via `SVN
   <http://svn.repoze.org/repoze.bfg.traversalwrapper>`_), then
   register its ``ModelGraphTraverser`` as the traversal policy, rather
-  than the default :mod:`pyramid` traverser. The package contains
+  than the default :app:`Pyramid` traverser. The package contains
   instructions.
 
-  Once :mod:`pyramid` is configured with this feature, you will no
+  Once :app:`Pyramid` is configured with this feature, you will no
   longer need to manage the ``__parent__`` and ``__name__`` attributes
   on graph objects "by hand".  Instead, as necessary, during traversal
-  :mod:`pyramid` will wrap each object (even the root object) in a
+  :app:`Pyramid` will wrap each object (even the root object) in a
   ``LocationProxy`` which will dynamically assign a ``__name__`` and a
   ``__parent__`` to the traversed object (based on the last traversed
   object and the name supplied to ``__getitem__``).  The root object
@@ -255,7 +255,7 @@ Applications which use :term:`traversal` to locate the :term:`context`
 of a view must ensure that the model instances that make up the model
 graph are "location aware".
 
-In order for :mod:`pyramid` location, security, URL-generation, and
+In order for :app:`Pyramid` location, security, URL-generation, and
 traversal functions (such as the functions exposed in
 :ref:`location_module`, :ref:`traversal_module`, and :ref:`url_module`
 as well as certain functions in :ref:`security_module` ) to work
@@ -300,7 +300,7 @@ and so on.
    single: model API functions
    single: url generation (traversal)
 
-:mod:`pyramid` API Functions That Act Against Models
+:app:`Pyramid` API Functions That Act Against Models
 -------------------------------------------------------
 
 A model instance is used as the :term:`context` argument provided to a
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 15b9bfde5..7815106ee 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -1,13 +1,13 @@
 .. _project_narr:
 
-Creating a :mod:`pyramid` Project
+Creating a :app:`Pyramid` Project
 ====================================
 
-It's possible to create a :mod:`pyramid` application completely
+It's possible to create a :app:`Pyramid` application completely
 manually, but it's usually more convenient to use a template to
-generate a basic :mod:`pyramid` application structure.
+generate a basic :app:`Pyramid` application structure.
 
-:mod:`pyramid` comes with templates that you can use to generate a
+:app:`Pyramid` comes with templates that you can use to generate a
 project.  Each template makes different configuration assumptions
 about what type of application you're trying to construct.
 
@@ -28,10 +28,10 @@ templates".
 
 .. _additional_paster_templates:
 
-Paster Templates Included with :mod:`pyramid`
+Paster Templates Included with :app:`Pyramid`
 ------------------------------------------------
 
-The convenience ``paster`` templates included with :mod:`pyramid`
+The convenience ``paster`` templates included with :app:`Pyramid`
 differ from each other on a number of axes:
 
 - the persistence mechanism they offer (no persistence mechanism,
@@ -93,7 +93,7 @@ Creating the Project
 
 In :ref:`installing_chapter`, you created a virtual Python
 environment via the ``virtualenv`` command.  To start a
-:mod:`pyramid` :term:`project`, use the ``paster`` facility
+:app:`Pyramid` :term:`project`, use the ``paster`` facility
 installed within the virtualenv.  In :ref:`installing_chapter` we
 called the virtualenv directory ``env``; the following command
 assumes that our current working directory is that directory.
@@ -153,7 +153,7 @@ application.
 
 The ``MyProject`` project directory contains an additional subdirectory named
 ``myproject`` (note the case difference) representing a Python
-:term:`package` which holds very simple :mod:`pyramid` sample code.  This is
+:term:`package` which holds very simple :app:`Pyramid` sample code.  This is
 where you'll edit your application's Python code and templates.
 
 .. index::
@@ -241,7 +241,7 @@ The Interactive Shell
 
 Once you've installed your program for development using ``setup.py
 develop``, you can use an interactive Python shell to examine your
-:mod:`pyramid` application :term:`model` and :term:`view` objects from
+:app:`Pyramid` application :term:`model` and :term:`view` objects from
 a Python prompt.  To do so, use the ``paster`` shell command with the
 ``pshell`` argument:
 
@@ -293,7 +293,7 @@ Python interpreter shell unconditionally.
 
 You should always use a section name argument that refers to the
 actual ``app`` section within the Paste configuration file that points
-at your :mod:`pyramid` application *without any middleware wrapping*.
+at your :app:`Pyramid` application *without any middleware wrapping*.
 In particular, a section name is inappropriate as the second argument
 to ``pshell`` if the configuration section it names is a ``pipeline``
 rather than an ``app``.  For example, if you have the following
@@ -356,14 +356,14 @@ Here's sample output from a run of ``paster serve``:
    Starting server in PID 16601.
    serving on 0.0.0.0:6543 view at http://127.0.0.1:6543
 
-By default, :mod:`pyramid` applications generated from a ``paster``
+By default, :app:`Pyramid` applications generated from a ``paster``
 template will listen on TCP port 6543.
 
 During development, it's often useful to run ``paster serve`` using
 its ``--reload`` option.  When ``--reload`` is passed to ``paster
 serve``, changes to any Python module your project uses will cause the
 server to restart.  This typically makes development easier, as
-changes to Python code made within a :mod:`pyramid` application is
+changes to Python code made within a :app:`Pyramid` application is
 not put into effect until the server restarts.
 
 For example:
@@ -383,16 +383,16 @@ runtime behavior, see :ref:`environment_chapter`.
 Using an Alternate WSGI Server
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The code generated by :mod:`pyramid` ``paster`` templates assumes
+The code generated by :app:`Pyramid` ``paster`` templates assumes
 that you will be using the ``paster serve`` command to start your
 application while you do development.  However, ``paster serve`` is by
-no means the only way to start up and serve a :mod:`pyramid`
+no means the only way to start up and serve a :app:`Pyramid`
 application.  As we saw in :ref:`configuration_narr`, ``paster serve``
-needn't be invoked at all to run a :mod:`pyramid` application.  The
-use of ``paster serve`` to run a :mod:`pyramid` application is
+needn't be invoked at all to run a :app:`Pyramid` application.  The
+use of ``paster serve`` to run a :app:`Pyramid` application is
 purely conventional based on the output of its ``paster`` templates.
 
-Any :term:`WSGI` server is capable of running a :mod:`pyramid`
+Any :term:`WSGI` server is capable of running a :app:`Pyramid`
 application.  Some WSGI servers don't require the :term:`PasteDeploy`
 framework's ``paster serve`` command to do server process management
 at all.  Each :term:`WSGI` server has its own documentation about how
@@ -402,7 +402,7 @@ concepts are largely the same, whatever server you happen to use.
 
 One popular production alternative to a ``paster``-invoked server is
 :term:`mod_wsgi`. You can also use :term:`mod_wsgi` to serve your
-:mod:`pyramid` application using the Apache web server rather than
+:app:`Pyramid` application using the Apache web server rather than
 any "pure-Python" server that is started as a result of ``paster
 serve``.  See :ref:`modwsgi_tutorial` for details.  However, it is
 usually easier to *develop* an application using a ``paster serve``
@@ -427,11 +427,11 @@ This is the page shown by default when you visit an unmodified
 The Project Structure
 ---------------------
 
-Our generated :mod:`pyramid` ``pyramid_starter`` application is a setuptools
+Our generated :app:`Pyramid` ``pyramid_starter`` application is a setuptools
 :term:`project` (named ``MyProject``), which contains a Python
 :term:`package` (which is *also* named ``myproject``, but lowercased; the
 paster template generates a project which contains a package that shares its
-name except for case).  All :mod:`pyramid` ``paster`` -generated projects
+name except for case).  All :app:`Pyramid` ``paster`` -generated projects
 share a similar structure.
 
 The ``MyProject`` project we've generated has the following directory
@@ -555,7 +555,7 @@ module).  You can provide startup-time configuration parameters to
 your application by requiring more settings in this section.
 
 The ``reload_templates`` setting in the ``[app:main]`` section is a
-:mod:`pyramid` -specific setting which is passed into the
+:app:`Pyramid` -specific setting which is passed into the
 framework.  If it exists, and its value is ``true``, :term:`Chameleon`
 template changes will not require an application restart to be
 detected.  See :ref:`reload_templates_section` for more information.
@@ -565,7 +565,7 @@ detected.  See :ref:`reload_templates_section` for more information.
    turned on.
 
 The ``debug_templates`` setting in the ``[app:main]`` section is a
-:mod:`pyramid` -specific setting which is passed into the
+:app:`Pyramid` -specific setting which is passed into the
 framework.  If it exists, and its value is ``true``, :term:`Chameleon`
 template exceptions will contained more detailed and helpful
 information about the error than when this value is ``false``.  See
@@ -576,7 +576,7 @@ information about the error than when this value is ``false``.  See
    turned on.
 
 Various other settings may exist in this section having to do with
-debugging or influencing runtime behavior of a :mod:`pyramid`
+debugging or influencing runtime behavior of a :app:`Pyramid`
 application.  See :ref:`environment_chapter` for more information
 about these settings.
 
@@ -587,9 +587,9 @@ will create a new thread for each request.
 
 .. note::
 
-  In general, :mod:`pyramid` applications generated from ``paster
+  In general, :app:`Pyramid` applications generated from ``paster
   templates`` should be threading-aware.  It is not required that a
-  :mod:`pyramid` application be nonblocking as all application code
+  :app:`Pyramid` application be nonblocking as all application code
   will run in its own thread, provided by the server you're using.
 
 See the :term:`PasteDeploy` documentation for more information about
@@ -718,7 +718,7 @@ The ``myproject`` :term:`package` lives inside the ``MyProject``
    application.
 
 These are purely conventions established by the ``paster`` template:
-:mod:`pyramid` doesn't insist that you name things in any
+:app:`Pyramid` doesn't insist that you name things in any
 particular way.
 
 .. index::
@@ -741,7 +741,7 @@ also informs Python that the directory which contains it is a *package*.
 #. Line 2 imports the ``get_root`` function from
    :mod:`myproject.models` that we use later.
 
-#. Lines 4-17 define a function that returns a :mod:`pyramid`
+#. Lines 4-17 define a function that returns a :app:`Pyramid`
    WSGI application.  This function is meant to be called
    by the :term:`PasteDeploy` framework as a result of running
    ``paster serve``.
@@ -772,9 +772,9 @@ also informs Python that the directory which contains it is a *package*.
 ``views.py``
 ~~~~~~~~~~~~
 
-Much of the heavy lifting in a :mod:`pyramid` application comes in
+Much of the heavy lifting in a :app:`Pyramid` application comes in
 the form of *view callables*.  A :term:`view callable` is the main
-tool of a :mod:`pyramid` web application developer; it is a bit of
+tool of a :app:`Pyramid` web application developer; it is a bit of
 code which accepts a :term:`request` and which returns a
 :term:`response`.
 
@@ -832,13 +832,13 @@ named ``MyModel`` that provides the behavior.
 #. Line 4 defines an instance of MyModel as the root.
 
 #. Line 6 is a "root factory" function that will be called by the
-   :mod:`pyramid` *Router* for each request when it wants to find
+   :app:`Pyramid` *Router* for each request when it wants to find
    the root of the object graph.  Conventionally this is called
    ``get_root``.
 
 In a "real" application, the root object would not be such a simple
 object.  Instead, it would be an object that could access some
-persistent data store, such as a database.  :mod:`pyramid` doesn't
+persistent data store, such as a database.  :app:`Pyramid` doesn't
 make any assumption about which sort of datastore you'll want to use,
 so the sample application uses an instance of
 :class:`myproject.models.MyModel` to represent the root.
@@ -876,8 +876,8 @@ The ``tests.py`` module includes unit tests for your application.
 This sample ``tests.py`` file has a single unit test defined within
 it.  This test is executed when you run ``python setup.py test``.  You
 may add more tests here as you build your application.  You are not
-required to write tests to use :mod:`pyramid`, this file is simply
+required to write tests to use :app:`Pyramid`, this file is simply
 provided as convenience and example.
 
 See :ref:`unittesting_chapter` for more information about writing
-:mod:`pyramid` unit tests.
+:app:`Pyramid` unit tests.
diff --git a/docs/narr/resources.rst b/docs/narr/resources.rst
index 621db577d..e98c34595 100644
--- a/docs/narr/resources.rst
+++ b/docs/narr/resources.rst
@@ -22,7 +22,7 @@ example, each of the following is a resource:
   in it (if it possessed an ``__init__.py`` it would *be* a package).
 
 The use of resources is quite common in most web development projects.
-For example, when you create a :mod:`pyramid` application using one
+For example, when you create a :app:`Pyramid` application using one
 of the available "paster" templates, as described in
 :ref:`creating_a_project`, the directory representing the application
 contains a Python :term:`package`.  Within that Python package, there
@@ -36,7 +36,7 @@ files.
 Understanding Resources
 -----------------------
 
-Let's imagine you've created a :mod:`pyramid` application that uses
+Let's imagine you've created a :app:`Pyramid` application that uses
 a :term:`Chameleon` ZPT template via the
 :func:`pyramid.chameleon_zpt.render_template_to_response` API.  For
 example, the application might address the resource named
@@ -50,20 +50,20 @@ file inside a ``myapp`` package:
    from pyramid.chameleon_zpt import render_template_to_response
    render_template_to_response('templates/some_template.pt')
 
-"Under the hood", when this API is called, :mod:`pyramid` attempts
+"Under the hood", when this API is called, :app:`Pyramid` attempts
 to make sense out of the string ``templates/some_template.pt``
 provided by the developer.  To do so, it first finds the "current"
 package.  The "current" package is the Python package in which the
 ``views.py`` module which contains this code lives.  This would be the
 ``myapp`` package, according to our example so far.  By resolving the
-current package, :mod:`pyramid` has enough information to locate
+current package, :app:`Pyramid` has enough information to locate
 the actual template file.  These are the elements it needs:
 
 - The *package name* (``myapp``)
 
 - The *resource name* (``templates/some_template.pt``)
 
-:mod:`pyramid` uses the :term:`pkg_resources` API to resolve the
+:app:`Pyramid` uses the :term:`pkg_resources` API to resolve the
 package name and resource name to an absolute
 (operating-system-specific) file name.  It eventually passes this
 resolved absolute filesystem path to the Chameleon templating engine,
@@ -82,8 +82,8 @@ Overriding Resources
 --------------------
 
 It can often be useful to override specific resources "from outside" a
-given :mod:`pyramid` application.  For example, you may wish to
-reuse an existing :mod:`pyramid` application more or less
+given :app:`Pyramid` application.  For example, you may wish to
+reuse an existing :app:`Pyramid` application more or less
 unchanged.  However, some specific template file owned by the
 application might have inappropriate HTML, or some static resource
 (such as a logo file or some CSS file) might not be appropriate.  You
@@ -95,7 +95,7 @@ customers (such as a CMS application, or some bug tracking
 application), and you want to make arbitrary visual modifications to a
 particular application deployment without forking the underlying code.
 
-To this end, :mod:`pyramid` contains a feature that makes it
+To this end, :app:`Pyramid` contains a feature that makes it
 possible to "override" one resource with one or more other resources.
 In support of this feature, a :term:`ZCML` directive exists named
 ``resource``.  The ``resource`` directive allows you to *override* the
@@ -118,7 +118,7 @@ Usually, overriding a resource in an existing application means
 performing the following steps:
 
 - Create a new Python package.  The easiest way to do this is to
-  create a new :mod:`pyramid` application using the "paster"
+  create a new :app:`Pyramid` application using the "paster"
   template mechanism.  See :ref:`creating_a_project` for more
   information.
 
@@ -129,7 +129,7 @@ performing the following steps:
 - Change the ``configure.zcml`` in the new package to include one or
   more ``resource`` ZCML directives (see :ref:`resource_directive`
   below).  The new package's ``configure.zcml`` should then include
-  the original :mod:`pyramid` application's ``configure.zcml`` via
+  the original :app:`Pyramid` application's ``configure.zcml`` via
   an include statement, e.g.  ``<include
   package="theoriginalpackage"/>``.
 
@@ -142,7 +142,7 @@ performing the following steps:
   for more information about this setting.
 
 Note that overriding resources is not the only way to extend or modify
-the behavior of an existing :mod:`pyramid` application.  A "heavier
+the behavior of an existing :app:`Pyramid` application.  A "heavier
 hammer" way to do the same thing is explained in
 :ref:`extending_chapter`.  The heavier hammer way allows you to
 replace a :term:`view` wholesale rather than resources that might be
@@ -250,7 +250,7 @@ Instead of using
 all the tasks described above within :term:`ZCML`.  The ZCML
 ``resource`` tag is a frontend to using ``override_resource``.
 
-An individual :mod:`pyramid` ``resource`` ZCML statement can
+An individual :app:`Pyramid` ``resource`` ZCML statement can
 override a single resource.  For example:
 
 .. code-block:: xml
diff --git a/docs/narr/router.rst b/docs/narr/router.rst
index b585482ef..b106d02db 100644
--- a/docs/narr/router.rst
+++ b/docs/narr/router.rst
@@ -8,27 +8,27 @@
 Request Processing
 ==================
 
-Once a :mod:`pyramid` application is up and running, it is ready to
+Once a :app:`Pyramid` application is up and running, it is ready to
 accept requests and return responses.
 
 What happens from the time a :term:`WSGI` request enters a
-:mod:`pyramid` application through to the point that
-:mod:`pyramid` hands off a response back to WSGI for upstream
+:app:`Pyramid` application through to the point that
+:app:`Pyramid` hands off a response back to WSGI for upstream
 processing?
 
 #. A user initiates a request from his browser to the hostname and
-   port number of the WSGI server used by the :mod:`pyramid`
+   port number of the WSGI server used by the :app:`Pyramid`
    application.
 
-#. The WSGI server used by the :mod:`pyramid` application passes
+#. The WSGI server used by the :app:`Pyramid` application passes
    the WSGI environment to the ``__call__`` method of the
-   :mod:`pyramid` :term:`router` object.
+   :app:`Pyramid` :term:`router` object.
 
 #. A :term:`request` object is created based on the WSGI environment.
 
 #. The :term:`application registry` and the :term:`request` object
    created in the last step are pushed on to the :term:`thread local`
-   stack that :mod:`pyramid` uses to allow the functions named
+   stack that :app:`Pyramid` uses to allow the functions named
    :func:`pyramid.threadlocal.get_current_request` and
    :func:`pyramid.threadlocal.get_current_registry` to work.
 
@@ -36,7 +36,7 @@ processing?
    subscribers.
 
 #. If any :term:`route` has been defined within application
-   configuration, the :mod:`pyramid` :term:`router` calls a
+   configuration, the :app:`Pyramid` :term:`router` calls a
    :term:`URL dispatch` "route mapper."  The job of the mapper is to
    examine the request to determine whether any user-defined
    :term:`route` matches the current WSGI environment.  The
@@ -59,7 +59,7 @@ processing?
    argument passed to the Configurator constructor was ``None``, a
    default root factory is used to generate a root object.
 
-#. The :mod:`pyramid` router calls a "traverser" function with the
+#. The :app:`Pyramid` router calls a "traverser" function with the
    root object and the request.  The traverser function attempts to
    traverse the root object (using any existing ``__getitem__`` on the
    root object and subobjects) to find a :term:`context`.  If the root
@@ -77,32 +77,32 @@ processing?
 #. A :class:`pyramid.events.ContextFound` :term:`event` is
    sent to any subscribers.
 
-#. :mod:`pyramid` looks up a :term:`view` callable using the
+#. :app:`Pyramid` looks up a :term:`view` callable using the
    context, the request, and the view name.  If a view callable
    doesn't exist for this combination of objects (based on the type of
    the context, the type of the request, and the value of the view
    name, and any :term:`predicate` attributes applied to the view
-   configuration), :mod:`pyramid` raises a
+   configuration), :app:`Pyramid` raises a
    :class:`pyramid.exceptions.NotFound` exception, which is meant
    to be caught by a surrounding exception handler.
 
-#. If a view callable was found, :mod:`pyramid` attempts to call
+#. If a view callable was found, :app:`Pyramid` attempts to call
    the view function.
 
 #. If an :term:`authorization policy` is in use, and the view was
-   protected by a :term:`permission`, :mod:`pyramid` passes the
+   protected by a :term:`permission`, :app:`Pyramid` passes the
    context, the request, and the view_name to a function which
    determines whether the view being asked for can be executed by the
    requesting user, based on credential information in the request and
    security information attached to the context.  If it returns
-   ``True``, :mod:`pyramid` calls the view callable to obtain a
+   ``True``, :app:`Pyramid` calls the view callable to obtain a
    response.  If it returns ``False``, it raises a
    :class:`pyramid.exceptions.Forbidden` exception, which is meant
    to be called by a surrounding exception handler.
 
 #. If any exception was raised within a :term:`root factory`, by
    :term:`traversal`, by a :term:`view callable` or by
-   :mod:`pyramid` itself (such as when it raises
+   :app:`Pyramid` itself (such as when it raises
    :class:`pyramid.exceptions.NotFound` or
    :class:`pyramid.exceptions.Forbidden`), the router catches the
    exception, and attaches it to the request as the ``exception``
@@ -114,7 +114,7 @@ processing?
 
 #. The following steps occur only when a :term:`response` could be
    successfully generated by a normal :term:`view callable` or an
-   :term:`exception view` callable.  :mod:`pyramid` will attempt to execute
+   :term:`exception view` callable.  :app:`Pyramid` will attempt to execute
    any :term:`response callback` functions attached via
    :meth:`pyramid.request.Request.add_response_callback`.  A
    :class:`pyramid.events.NewResponse` :term:`event` is then sent to any
@@ -122,7 +122,7 @@ processing?
    ``headerlist`` attributes are then used to generate a WSGI response.  The
    response is sent back to the upstream WSGI server.
 
-#. :mod:`pyramid` will attempt to execute any :term:`finished
+#. :app:`Pyramid` will attempt to execute any :term:`finished
    callback` functions attached via
    :meth:`pyramid.request.Request.add_finished_callback`.
 
@@ -131,7 +131,7 @@ processing?
 .. image:: router.png
 
 This is a very high-level overview that leaves out various details.
-For more detail about subsystems invoked by the :mod:`pyramid` router
+For more detail about subsystems invoked by the :app:`Pyramid` router
 such as traversal, URL dispatch, views, and event processing, see
 :ref:`contextfinding_chapter`, :ref:`views_chapter`, and
 :ref:`events_chapter`.
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index f9fee59dd..8cf459880 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -6,7 +6,7 @@
 Security
 ========
 
-:mod:`pyramid` provides an optional declarative authorization
+:app:`Pyramid` provides an optional declarative authorization
 system that prevents a :term:`view` from being invoked when the user
 represented by credentials in the :term:`request` does not have an
 appropriate level of access within a particular :term:`context`.
@@ -43,8 +43,8 @@ Here's how it works at a high level:
 
 Authorization is enabled by modifying your application to include an
 :term:`authentication policy` and :term:`authorization policy`.
-:mod:`pyramid` comes with a variety of implementations of these
-policies.  To provide maximal flexibility, :mod:`pyramid` also
+:app:`Pyramid` comes with a variety of implementations of these
+policies.  To provide maximal flexibility, :app:`Pyramid` also
 allows you to create custom authentication policies and authorization
 policies.
 
@@ -54,7 +54,7 @@ policies.
 Enabling an Authorization Policy
 --------------------------------
 
-By default, :mod:`pyramid` enables no authorization policy.  All
+By default, :app:`Pyramid` enables no authorization policy.  All
 views are accessible by completely anonymous users.  In order to begin
 protecting views from execution based on security settings, you need
 to enable an authorization policy.
@@ -174,7 +174,7 @@ registered view always be executable by entirely anonymous users: any
 authorization policy in effect is ignored.
 
 In support of making it easier to configure applications which are
-"secure by default", :mod:`pyramid` allows you to configure a
+"secure by default", :app:`Pyramid` allows you to configure a
 *default* permission.  If supplied, the default permission is used as
 the permission string to all view registrations which don't otherwise
 name a ``permission`` argument.
@@ -211,7 +211,7 @@ When a default permission is registered:
 Assigning ACLs to your Model Objects
 ------------------------------------
 
-When the default :mod:`pyramid` :term:`authorization policy`
+When the default :app:`Pyramid` :term:`authorization policy`
 determines whether a user possesses a particular permission in a
 :term:`context`, it examines the :term:`ACL` associated with the
 context.  An ACL is associated with a context by virtue of the
@@ -479,7 +479,7 @@ location-awareness.  See also :ref:`location_aware`.
 Changing the Forbidden View
 ---------------------------
 
-When :mod:`pyramid` denies a view invocation due to an
+When :app:`Pyramid` denies a view invocation due to an
 authorization denial, the special ``forbidden`` view is invoked.  "Out
 of the box", this forbidden view is very plain.  See
 :ref:`changing_the_forbidden_view` within :ref:`hooks_chapter` for
@@ -543,7 +543,7 @@ via print statements when a call to
 Creating Your Own Authentication Policy
 ---------------------------------------
 
-:mod:`pyramid` ships with a number of useful out-of-the-box
+:app:`Pyramid` ships with a number of useful out-of-the-box
 security policies (see :mod:`pyramid.authentication`).  However,
 creating your own authentication policy is often necessary when you
 want to control the "horizontal and vertical" of how your users
@@ -587,7 +587,7 @@ Creating Your Own Authorization Policy
 --------------------------------------
 
 An authorization policy is a policy that allows or denies access after
-a user has been authenticated.  By default, :mod:`pyramid` will use
+a user has been authenticated.  By default, :app:`Pyramid` will use
 the :class:`pyramid.authorization.ACLAuthorizationPolicy` if an
 authentication policy is activated and an authorization policy isn't
 otherwise specified.
@@ -599,7 +599,7 @@ example, it might be desirable to construct an alternate authorization
 policy which allows the application to use an authorization mechanism
 that does not involve :term:`ACL` objects.
 
-:mod:`pyramid` ships with only a single default authorization
+:app:`Pyramid` ships with only a single default authorization
 policy, so you'll need to create your own if you'd like to use a
 different one.  Creating and using your own authorization policy is a
 matter of creating an instance of an object that implements the
diff --git a/docs/narr/sessions.rst b/docs/narr/sessions.rst
index 43cb78410..eea035975 100644
--- a/docs/narr/sessions.rst
+++ b/docs/narr/sessions.rst
@@ -14,10 +14,10 @@ Using The Default Session Factory
 ---------------------------------
 
 In order to use sessions, you must set up a :term:`session factory`
-during your :mod:`pyramid` configuration.
+during your :app:`Pyramid` configuration.
 
 A very basic, insecure sample session factory implementation is
-provided in the :mod:`pyramid` core.  It uses a cookie to store
+provided in the :app:`Pyramid` core.  It uses a cookie to store
 session information.  This implementation has the following
 limitation:
 
@@ -33,7 +33,7 @@ limitation:
 It is, however, digitally signed, and thus its data cannot easily be
 tampered with.
 
-You can configure this session factory in your :mod:`pyramid`
+You can configure this session factory in your :app:`Pyramid`
 application by using the ``session_factory`` argument to the
 :class:`pyramid.configuration.Configurator` class:
 
@@ -149,7 +149,7 @@ Creating Your Own Session Factory
 ---------------------------------
 
 If none of the default or otherwise available sessioning
-implementations for :mod:`pyramid` suit you, you may create your own
+implementations for :app:`Pyramid` suit you, you may create your own
 session object by implementing a :term:`session factory`.  Your
 session factory should return a :term:`session`.  The interfaces for
 both types are available in
diff --git a/docs/narr/startup.rst b/docs/narr/startup.rst
index 7c4ee0897..9d9baf92d 100644
--- a/docs/narr/startup.rst
+++ b/docs/narr/startup.rst
@@ -3,7 +3,7 @@
 Startup
 =======
 
-When you cause :mod:`pyramid` to start up in a console window,
+When you cause :app:`Pyramid` to start up in a console window,
 you'll see something much like this show up on the console:
 
 .. code-block:: text
@@ -24,11 +24,11 @@ The Startup Process
 -------------------
 
 The easiest and best-documented way to start and serve a
-:mod:`pyramid` application is to use the ``paster serve`` command
+:app:`Pyramid` application is to use the ``paster serve`` command
 against a :term:`PasteDeploy` ``.ini`` file.  This uses the ``.ini``
 file to infer settings and starts a server listening on a port.  For
 the purposes of this discussion, we'll assume that you are using this
-command to run your :mod:`pyramid` application.
+command to run your :app:`Pyramid` application.
 
 Here's a high-level time-ordered overview of what happens when you
 press ``return`` after running ``paster serve development.ini``.
@@ -44,16 +44,16 @@ press ``return`` after running ``paster serve development.ini``.
    the ``.ini`` file.  This section represents the configuration of a
    :term:`WSGI` application that will be served.  If you're using a
    simple application (e.g. an ``[app:main]`` section of a
-   default-generated :mod:`pyramid` project), the application
+   default-generated :app:`Pyramid` project), the application
    :term:`entry point` or :term:`dotted Python name` will be named on
    the ``use=`` line within the section's configuration.  If, instead
    of a simple application, you're using a WSGI :term:`pipeline`
    (e.g. a ``[pipeline:main]`` section), the application named on the
-   "last" element will refer to your :mod:`pyramid` application.
+   "last" element will refer to your :app:`Pyramid` application.
    If instead of a simple application or a pipeline, you're using a
    Paste "composite" (e.g. ``[composite:main]``), refer to the
    documentation for that particular composite to understand how to
-   make it refer to your :mod:`pyramid` application.
+   make it refer to your :app:`Pyramid` application.
 
 #. The application's *constructor* (named by the entry point reference
    or dotted Python name on the ``use=`` line) is passed the key/value
@@ -61,10 +61,10 @@ press ``return`` after running ``paster serve development.ini``.
    constructor is meant to return a :term:`router` instance, which is
    a :term:`WSGI` application.
 
-   For :mod:`pyramid` applications, the constructor will be a function named
+   For :app:`Pyramid` applications, the constructor will be a function named
    ``app`` in the ``__init__.py`` file within the :term:`package` in which
    your application lives.  If this function succeeds, it will return a
-   :mod:`pyramid` :term:`router` instance.  Here's the contents of an example
+   :app:`Pyramid` :term:`router` instance.  Here's the contents of an example
    ``__init__.py`` module:
 
    .. literalinclude:: MyProject/myproject/__init__.py
@@ -112,7 +112,7 @@ press ``return`` after running ``paster serve development.ini``.
 #. The ``app`` function then calls various methods on the an instance of the
    class :class:`pyramid.configuration.Configurator` method.  The intent of
    calling these methods is to populate an :term:`application registry`,
-   which represents the :mod:`pyramid` configuration related to the
+   which represents the :app:`Pyramid` configuration related to the
    application.
 
 #. The :meth:`pyramid.configuration.Configurator.make_wsgi_app` method is
diff --git a/docs/narr/static.rst b/docs/narr/static.rst
index 90ee61f6c..e350bc693 100644
--- a/docs/narr/static.rst
+++ b/docs/narr/static.rst
@@ -1,9 +1,9 @@
 Static Resources
 ================
 
-:mod:`pyramid` makes it possible to serve up "static" (non-dynamic)
+:app:`Pyramid` makes it possible to serve up "static" (non-dynamic)
 resources from a directory on a filesystem.  This chapter describes
-how to configure :mod:`pyramid` to do so.
+how to configure :app:`Pyramid` to do so.
 
 .. index::
    single: add_static_view
@@ -14,7 +14,7 @@ Serving Static Resources
 ------------------------
 
 Use the :meth:`pyramid.configuration.Configurator.add_static_view` to
-instruct :mod:`pyramid` to serve static resources such as JavaScript and CSS
+instruct :app:`Pyramid` to serve static resources such as JavaScript and CSS
 files. This mechanism makes static files available at a name relative to the
 application root URL, e.g. ``/static``.
 
@@ -25,7 +25,7 @@ qualified :term:`resource specification` or an *absolute path*.
 Here's an example of a use of
 :meth:`pyramid.configuration.Configurator.add_static_view` that will serve
 files up under the ``/static`` URL from the ``/var/www/static`` directory of
-the computer which runs the :mod:`pyramid` application using an absolute
+the computer which runs the :app:`Pyramid` application using an absolute
 path.
 
 .. code-block:: python
@@ -169,7 +169,7 @@ of a static URL declaration, the generated URLs will continue to resolve
 properly after the rename.
 
 URLs may also be generated by :func:`pyramid.url.static_url` to static
-resources that live *outside* the :mod:`pyramid` application.  This will
+resources that live *outside* the :app:`Pyramid` application.  This will
 happen when the :meth:`pyramid.configuration.Configurator.add_static_view`
 API associated with the path fed to :func:`pyramid.url.static_url` is a *URL*
 instead of a view name.  For example, the ``name`` argument may be
@@ -204,7 +204,7 @@ type.
 
 The :class:`pyramid.view.static` helper class is used to perform
 this task. This class creates an object that is capable acting as a
-:mod:`pyramid` view callable which serves static resources from a
+:app:`Pyramid` view callable which serves static resources from a
 directory.  For instance, to serve files within a directory located on
 your filesystem at ``/path/to/static/dir`` mounted at the URL path
 ``/static`` in your application, create an instance of the
@@ -239,7 +239,7 @@ represents your root object.
                    context='mypackage.models.Root')
 
 In this case, ``mypackage.models.Root`` refers to the class of which your
-:mod:`pyramid` application's root object is an instance.
+:app:`Pyramid` application's root object is an instance.
 
 You can also omit the ``context`` argument if you want the name ``static`` to
 be accessible as the static view against any model.  This will also allow
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 9722db6b2..f7929b44e 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -4,17 +4,17 @@ Templates
 =========
 
 A :term:`template` is a file on disk which can be used to render
-dynamic data provided by a :term:`view`.  :mod:`pyramid` offers a
+dynamic data provided by a :term:`view`.  :app:`Pyramid` offers a
 number of ways to perform templating tasks out of the box, and
 provides add-on templating support through a set of bindings packages.
 
-Out of the box, :mod:`pyramid` provides templating via the :term:`Chameleon`
+Out of the box, :app:`Pyramid` provides templating via the :term:`Chameleon`
 and :term:`Mako` templating libraries. :term:`Chameleon` provides support for
 two different types of templates: :term:`ZPT` templates and text templates.
 
 Before discussing how built-in templates are used in
 detail, we'll discuss two ways to render templates within
-:mod:`pyramid` in general: directly, and via renderer
+:app:`Pyramid` in general: directly, and via renderer
 configuration.
 
 .. index::
@@ -26,11 +26,11 @@ Templates Used Directly
 -----------------------
 
 The most straightforward way to use a template within
-:mod:`pyramid` is to cause it to be rendered directly within a
+:app:`Pyramid` is to cause it to be rendered directly within a
 :term:`view callable`.  You may use whatever API is supplied by a
 given templating engine to do so.
 
-:mod:`pyramid` provides various APIs that allow you to render
+:app:`Pyramid` provides various APIs that allow you to render
 templates directly from within a view callable.  For example, if there
 is a :term:`Chameleon` ZPT template named ``foo.pt`` in a directory in
 your application named ``templates``, you can render the template from
@@ -56,7 +56,7 @@ within the body of a view callable like so:
    Application developers are encouraged instead to use the functions
    available in the :mod:`pyramid.renderers` module to perform
    rendering tasks.  This set of functions works to render templates
-   for all renderer extensions registered with :mod:`pyramid`.
+   for all renderer extensions registered with :app:`Pyramid`.
 
 The ``sample_view`` :term:`view callable` above returns a
 :term:`response` object which contains the body of the
@@ -115,7 +115,7 @@ containing them around.
    path, it is treated as an absolute resource specification.
 
 In the examples above we pass in a keyword argument named ``request``
-representing the current :mod:`pyramid` request. Passing a request
+representing the current :app:`Pyramid` request. Passing a request
 keyword argument will cause the ``render_to_response`` function to
 supply the renderer with more correct system values (see
 :ref:`renderer_system_values`), because most of the information
@@ -156,15 +156,15 @@ the body of the response:
        return response
 
 Because :term:`view callable` functions are typically the only code in
-:mod:`pyramid` that need to know anything about templates, and because view
+:app:`Pyramid` that need to know anything about templates, and because view
 functions are very simple Python, you can use whatever templating system you're
-most comfortable with within :mod:`pyramid`.  Install the templating system,
+most comfortable with within :app:`Pyramid`.  Install the templating system,
 import its API functions into your views module, use those APIs to generate a
-string, then return that string as the body of a :mod:`pyramid`
+string, then return that string as the body of a :app:`Pyramid`
 :term:`Response` object.
 
 For example, here's an example of using "raw" `Mako
-<http://www.makotemplates.org/>`_ from within a :mod:`pyramid` :term:`view`:
+<http://www.makotemplates.org/>`_ from within a :app:`Pyramid` :term:`view`:
 
 .. ignore-next-block
 .. code-block:: python
@@ -181,21 +181,21 @@ For example, here's an example of using "raw" `Mako
 
 You probably wouldn't use this particular snippet in a project, because it's
 easier to use the Mako renderer bindings which already exist in
-:mod:`pyramid`. But if your favorite templating system is not supported as a
-renderer extension for :mod:`pyramid`, you can create your own simple
+:app:`Pyramid`. But if your favorite templating system is not supported as a
+renderer extension for :app:`Pyramid`, you can create your own simple
 combination as shown above.
 
 .. note::
 
    If you use third-party templating languages without cooperating
-   :mod:`pyramid` bindings directly within view callables, the
+   :app:`Pyramid` bindings directly within view callables, the
    auto-template-reload strategy explained in
    :ref:`reload_templates_section` will not be available, nor will the
    template resource overriding capability explained in
    :ref:`overriding_resources_section` be available, nor will it be
    possible to use any template using that language as a
    :term:`renderer`.  However, it's reasonably easy to write custom
-   templating system binding packages for use under :mod:`pyramid` so
+   templating system binding packages for use under :app:`Pyramid` so
    that templates written in the language can be used as renderers.
    See :ref:`adding_and_overriding_renderers` for instructions on how
    to create your own template renderer and
@@ -257,7 +257,7 @@ template will be provided with a number of *system* values.  These
 values are provided in a dictionary to the renderer and include:
 
 ``context``
-  The current :mod:`pyramid` context if ``request`` was provided as
+  The current :app:`Pyramid` context if ``request`` was provided as
   a keyword argument or ``None``.
 
 ``request``
@@ -344,11 +344,11 @@ specification` in the form ``some.dotted.package_name:relative/path``, making
 it possible to address template resources which live in another package.
 
 Not just any template from any arbitrary templating system may be used as a
-renderer.  Bindings must exist specifically for :mod:`pyramid` to use a
-templating language template as a renderer.  Currently, :mod:`pyramid` has
+renderer.  Bindings must exist specifically for :app:`Pyramid` to use a
+templating language template as a renderer.  Currently, :app:`Pyramid` has
 built-in support for two Chameleon templating languages: ZPT and text, and
 the Mako templating system.  See :ref:`built_in_renderers` for a discussion
-of their details.  :mod:`pyramid` also supports the use of :term:`Jinja2`
+of their details.  :app:`Pyramid` also supports the use of :term:`Jinja2`
 templates as renderers.  See :ref:`available_template_system_bindings`.
 
 .. sidebar:: Why Use A Renderer via View Configuration
@@ -393,9 +393,9 @@ imperatively.  See :ref:`renderer_system_values`.
 :term:`Chameleon` ZPT Templates
 -------------------------------
 
-Like :term:`Zope`, :mod:`pyramid` uses :term:`ZPT` (Zope Page
+Like :term:`Zope`, :app:`Pyramid` uses :term:`ZPT` (Zope Page
 Templates) as its default templating language.  However,
-:mod:`pyramid` uses a different implementation of the :term:`ZPT`
+:app:`Pyramid` uses a different implementation of the :term:`ZPT`
 specification than Zope does: the :term:`Chameleon` templating
 engine. The Chameleon engine complies largely with the `Zope Page
 Template <http://wiki.zope.org/ZPT/FrontPage>`_ template
@@ -436,7 +436,7 @@ A Sample ZPT Template
 ~~~~~~~~~~~~~~~~~~~~~
 
 Here's what a simple :term:`Chameleon` ZPT template used under
-:mod:`pyramid` might look like:
+:app:`Pyramid` might look like:
 
 .. code-block:: xml
    :linenos:
@@ -469,17 +469,17 @@ works in these templates.
    single: ZPT macros
    single: Chameleon ZPT macros
 
-Using ZPT Macros in :mod:`pyramid`
+Using ZPT Macros in :app:`Pyramid`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When a :term:`renderer` is used to render a template,
-:mod:`pyramid` makes at least two top-level names available to the
+:app:`Pyramid` makes at least two top-level names available to the
 template by default: ``context`` and ``request``.  One of the common
 needs in ZPT-based templates is to use one template's "macros" from within
 a different template.  In Zope, this is typically handled by
 retrieving the template from the ``context``.  But having a hold of
-the context in :mod:`pyramid` is not helpful: templates cannot
-usually be retrieved from models.  To use macros in :mod:`pyramid`,
+the context in :app:`Pyramid` is not helpful: templates cannot
+usually be retrieved from models.  To use macros in :app:`Pyramid`,
 you need to make the macro template itself available to the rendered
 template by passing the template in which the macro is defined (or even
 the macro itself) *into* the rendered template.  To make a macro
@@ -536,7 +536,7 @@ And ``templates/mytemplate.pt`` might look like so:
 Templating with :term:`Chameleon` Text Templates
 ------------------------------------------------
 
-:mod:`pyramid` also allows for the use of templates which are
+:app:`Pyramid` also allows for the use of templates which are
 composed entirely of non-XML text via :term:`Chameleon`.  To do so,
 you can create templates that are entirely composed of text except for
 ``${name}`` -style substitution points.
@@ -606,7 +606,7 @@ Nicer Exceptions in Chameleon Templates
 ---------------------------------------
 
 The exceptions raised by Chameleon templates when a rendering fails
-are sometimes less than helpful.  :mod:`pyramid` allows you to
+are sometimes less than helpful.  :app:`Pyramid` allows you to
 configure your application development environment so that exceptions
 generated by Chameleon during template compilation and execution will
 contain nicer debugging information.
@@ -688,7 +688,7 @@ templates.
 Templating With Mako Templates
 ------------------------------
 
-:term:`Mako` is a templating system written by Mike Bayer.  :mod:`pyramid`
+:term:`Mako` is a templating system written by Mike Bayer.  :app:`Pyramid`
 has built-in bindings for the Mako templating system.  The language
 definition documentation for Mako templates is available from `the Mako
 website <http://www.makotemplates.org/>`_.
@@ -723,7 +723,7 @@ placed into the application's ``ini`` file.
 A Sample Mako Template
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Here's what a simple :term:`Mako` template used under :mod:`pyramid` might
+Here's what a simple :term:`Mako` template used under :app:`Pyramid` might
 look like:
 
 .. code-block:: xml
@@ -761,7 +761,7 @@ Automatically Reloading Templates
 
 It's often convenient to see changes you make to a template file
 appear immediately without needing to restart the application process.
-:mod:`pyramid` allows you to configure your application development
+:app:`Pyramid` allows you to configure your application development
 environment so that a change to a template will be automatically
 detected, and the template will be reloaded on the next rendering.
 
@@ -795,7 +795,7 @@ application's configuration section, e.g.::
 Available Add-On Template System Bindings
 -----------------------------------------
 
-Jinja2 template bindings are available for :mod:`pyramid` in the
+Jinja2 template bindings are available for :app:`Pyramid` in the
 ``pyramid_jinja2`` package.  It lives in the Pylons version control
 repository at `http://github.com/Pylons/pyramid_jinja2
 <http://github.com/Pylons/pyramid_jinja2>`_.  At the time of this writing, it
diff --git a/docs/narr/threadlocals.rst b/docs/narr/threadlocals.rst
index 4fef96ef1..9b04d5914 100644
--- a/docs/narr/threadlocals.rst
+++ b/docs/narr/threadlocals.rst
@@ -14,15 +14,15 @@ true global variable, one thread or process serving the application
 may receive a different value than another thread or process when that
 variable is "thread local".
 
-When a request is processed, :mod:`pyramid` makes two :term:`thread
+When a request is processed, :app:`Pyramid` makes two :term:`thread
 local` variables available to the application: a "registry" and a
 "request".
 
-Why and How :mod:`pyramid` Uses Thread Local Variables
+Why and How :app:`Pyramid` Uses Thread Local Variables
 ---------------------------------------------------------
 
-How are thread locals beneficial to :mod:`pyramid` and application
-developers who use :mod:`pyramid`?  Well, usually they're decidedly
+How are thread locals beneficial to :app:`Pyramid` and application
+developers who use :app:`Pyramid`?  Well, usually they're decidedly
 **not**.  Using a global or a thread local variable in any application
 usually makes it a lot harder to understand for a casual reader.  Use
 of a thread local or a global is usually just a way to avoid passing
@@ -30,7 +30,7 @@ some value around between functions, which is itself usually a very
 bad idea, at least if code readability counts as an important concern.
 
 For historical reasons, however, thread local variables are indeed
-consulted by various :mod:`pyramid` API functions.  For example,
+consulted by various :app:`Pyramid` API functions.  For example,
 the implementation of the :mod:`pyramid.security` function named
 :func:`pyramid.security.authenticated_userid` retrieves the thread
 local :term:`application registry` as a matter of course to find an
@@ -38,10 +38,10 @@ local :term:`application registry` as a matter of course to find an
 :func:`pyramid.threadlocal.get_current_registry` function to
 retrieve the application registry, from which it looks up the
 authentication policy; it then uses the authentication policy to
-retrieve the authenticated user id.  This is how :mod:`pyramid`
+retrieve the authenticated user id.  This is how :app:`Pyramid`
 allows arbitrary authentication policies to be "plugged in".
 
-When they need to do so, :mod:`pyramid` internals use two API
+When they need to do so, :app:`Pyramid` internals use two API
 functions to retrieve the :term:`request` and :term:`application
 registry`: :func:`pyramid.threadlocal.get_current_request` and
 :func:`pyramid.threadlocal.get_current_registry`.  The former
@@ -52,13 +52,13 @@ thread-local data structure.  These API functions are documented in
 
 These values are thread locals rather than true globals because one
 Python process may be handling multiple simultaneous requests or even
-multiple :mod:`pyramid` applications.  If they were true globals,
-:mod:`pyramid` could not handle multiple simultaneous requests or
-allow more than one :mod:`pyramid` application instance to exist in
+multiple :app:`Pyramid` applications.  If they were true globals,
+:app:`Pyramid` could not handle multiple simultaneous requests or
+allow more than one :app:`Pyramid` application instance to exist in
 a single Python process.
 
-Because one :mod:`pyramid` application is permitted to call
-*another* :mod:`pyramid` application from its own :term:`view` code
+Because one :app:`Pyramid` application is permitted to call
+*another* :app:`Pyramid` application from its own :term:`view` code
 (perhaps as a :term:`WSGI` app with help from the
 :func:`pyramid.wsgi.wsgiapp2` decorator), these variables are
 managed in a *stack* during normal system operations.  The stack
@@ -82,7 +82,7 @@ calls to the :func:`pyramid.testing.setUp` and
 and pop the threadlocal stack when the system is under test.  See
 :ref:`test_setup_and_teardown` for the definitions of these functions.
 
-Scripts which use :mod:`pyramid` machinery but never actually start
+Scripts which use :app:`Pyramid` machinery but never actually start
 a WSGI server or receive requests via HTTP such as scripts which use
 the :mod:`pyramid.scripting` API will never cause any Router code
 to be executed.  However, the :mod:`pyramid.scripting` APIs also
@@ -131,8 +131,8 @@ follows:
 - Neither ``get_current_request`` nor ``get_current_registry`` should
   ever be called within application-specific forks of third-party
   library code.  The library you've forked almost certainly has
-  nothing to do with :mod:`pyramid`, and making it dependent on
-  :mod:`pyramid` (rather than making your :mod:`pyramid`
+  nothing to do with :app:`Pyramid`, and making it dependent on
+  :app:`Pyramid` (rather than making your :mod:`pyramid`
   application depend upon it) means you're forming a dependency in the
   wrong direction.
 
diff --git a/docs/narr/traversal.rst b/docs/narr/traversal.rst
index 545e7b3e2..56594ed5a 100644
--- a/docs/narr/traversal.rst
+++ b/docs/narr/traversal.rst
@@ -55,9 +55,9 @@ can run the ``cat`` command:
 
 The contents of ``myfile`` are now printed on the user's behalf.
 
-:mod:`pyramid` is very much like this inexperienced UNIX user as it
+:app:`Pyramid` is very much like this inexperienced UNIX user as it
 uses :term:`traversal` against an object graph.  In this analogy, we
-can map the ``cat`` program to the :mod:`pyramid` concept of a
+can map the ``cat`` program to the :app:`Pyramid` concept of a
 :term:`view callable`: it is a program that can be run against some
 :term:`context` as the result of :term:`view lookup`.  The file being
 operated on in this analogy is the :term:`context` object; the context
@@ -68,7 +68,7 @@ as a stop condition is analogous to :term:`traversal`.
 
 The analogy we've used is not *exactly* correct, because, while the
 naive user already knows which command he wants to invoke before he
-starts "traversing" (``cat``), :mod:`pyramid` needs to obtain that
+starts "traversing" (``cat``), :app:`Pyramid` needs to obtain that
 information from the path being traversed itself.  In
 :term:`traversal`, the "command" meant to be invoked is a :term:`view
 callable`.  A view callable is derived via :term:`view lookup` from
@@ -136,9 +136,9 @@ the traversal process *after* traversal finds a context object.
 
 The combination of the :term:`context` object and the :term:`view
 name` found via traversal is used later in the same request by a
-separate :mod:`pyramid` subsystem -- the :term:`view lookup`
+separate :app:`Pyramid` subsystem -- the :term:`view lookup`
 subsystem -- to find a :term:`view callable` later within the same
-request.  How :mod:`pyramid` performs view lookup is explained
+request.  How :app:`Pyramid` performs view lookup is explained
 within the :ref:`views_chapter` chapter.
 
 .. index::
@@ -152,11 +152,11 @@ The Object Graph
 ----------------
 
 When your application uses :term:`traversal` to resolve URLs to code,
-your application must supply an *object graph* to :mod:`pyramid`.
+your application must supply an *object graph* to :app:`Pyramid`.
 This graph is represented by a :term:`root` object.
 
 In order to supply a root object for an application, at system startup
-time, the :mod:`pyramid` :term:`Router` is configured with a
+time, the :app:`Pyramid` :term:`Router` is configured with a
 callback known as a :term:`root factory`.  The root factory is
 supplied by the application developer as the ``root_factory`` argument
 to the application's :term:`Configurator`.
@@ -181,7 +181,7 @@ named ``config``:
 
 Using the ``root_factory`` argument to a
 :class:`pyramid.configuration.Configurator` constructor tells your
-:mod:`pyramid` application to call this root factory to generate a
+:app:`Pyramid` application to call this root factory to generate a
 root object whenever a request enters the application.  This root
 factory is also known as the global root factory.  A root factory can
 alternately be passed to the ``Configurator`` as a :term:`dotted
@@ -197,7 +197,7 @@ with a database connection or another persistence mechanism.  A root
 object is often an instance of a class which has a ``__getitem__``
 method.
 
-If no :term:`root factory` is passed to the :mod:`pyramid`
+If no :term:`root factory` is passed to the :app:`Pyramid`
 :term:`Configurator` constructor, or the ``root_factory`` is specified
 as the value ``None``, a *default* root factory is used.  The default
 root factory always returns an object that has no child nodes.
@@ -226,7 +226,7 @@ root factory always returns an object that has no child nodes.
 
 Items contained within the object graph are sometimes analogous to the
 concept of :term:`model` objects used by many other frameworks (and
-:mod:`pyramid` APIs often refers to them as "models", as well).
+:app:`Pyramid` APIs often refers to them as "models", as well).
 They are typically instances of Python classes.
 
 The object graph consists of *container* nodes and *leaf* nodes.
@@ -269,7 +269,7 @@ until all path segments are exhausted.
 The Traversal Algorithm
 -----------------------
 
-This section will attempt to explain the :mod:`pyramid` traversal
+This section will attempt to explain the :app:`Pyramid` traversal
 algorithm.  We'll provide a description of the algorithm, a diagram of
 how the algorithm works, and some example traversal scenarios that
 might help you understand how the algorithm operates against a
@@ -278,7 +278,7 @@ specific object graph.
 We'll also talk a bit about :term:`view lookup`.  The
 :ref:`views_chapter` chapter discusses :term:`view lookup` in detail,
 and it is the canonical source for information about views.
-Technically, :term:`view lookup` is a :mod:`pyramid` subsystem that
+Technically, :term:`view lookup` is a :app:`Pyramid` subsystem that
 is separated from traversal entirely.  However, we'll describe the
 fundamental behavior of view lookup in the examples in the next few
 sections to give you an idea of how traversal and view lookup
@@ -298,7 +298,7 @@ When a user requests a page from your :mod:`traversal` -powered
 application, the system uses this algorithm to find a :term:`context`
 and a :term:`view name`.
 
-#.  The request for the page is presented to the :mod:`pyramid`
+#.  The request for the page is presented to the :app:`Pyramid`
     :term:`router` in terms of a standard :term:`WSGI` request, which
     is represented by a WSGI environment and a WSGI ``start_response``
     callable.
@@ -363,7 +363,7 @@ and a :term:`view name`.
 Once :term:`context` and :term:`view name` and associated attributes
 such as the :term:`subpath` are located, the job of :term:`traversal`
 is finished.  It passes back the information it obtained to its
-caller, the :mod:`pyramid` :term:`Router`, which subsequently
+caller, the :app:`Pyramid` :term:`Router`, which subsequently
 invokes :term:`view lookup` with the context and view name
 information.
 
@@ -445,7 +445,7 @@ lookup asks the :term:`application registry` this question:
   the class ``Bar``.
 
 Let's say that view lookup finds no matching view type.  In this
-circumstance, the :mod:`pyramid` :term:`router` returns the result
+circumstance, the :app:`Pyramid` :term:`router` returns the result
 of the :term:`not found view` and the request ends.
 
 However, for this graph::
@@ -516,7 +516,7 @@ expected to return a response.
    ``context`` attribute of the request object,
    e.g. ``request.context``.  The :term:`view name` is available as
    the ``view_name`` attribute of the request object,
-   e.g. ``request.view_name``.  Other :mod:`pyramid` -specific
+   e.g. ``request.view_name``.  Other :app:`Pyramid` -specific
    request attributes are also available as described in
    :ref:`special_request_attributes`.
 
@@ -524,7 +524,7 @@ References
 ----------
 
 A tutorial showing how :term:`traversal` can be used within a
-:mod:`pyramid` application exists in :ref:`bfg_wiki_tutorial`.
+:app:`Pyramid` application exists in :ref:`bfg_wiki_tutorial`.
 
 See the :ref:`views_chapter` chapter for detailed information about
 :term:`view lookup`.
diff --git a/docs/narr/unittesting.rst b/docs/narr/unittesting.rst
index 85f74ec0a..5cd8a0683 100644
--- a/docs/narr/unittesting.rst
+++ b/docs/narr/unittesting.rst
@@ -46,15 +46,15 @@ measure of assurance that your "units" work together, as they will be
 expected to when your application is run in production.
 
 The suggested mechanism for unit and integration testing of a
-:mod:`pyramid` application is the Python :mod:`unittest` module.
+:app:`Pyramid` application is the Python :mod:`unittest` module.
 Although this module is named :mod:`unittest`, it is actually capable
 of driving both unit and integration tests.  A good :mod:`unittest`
 tutorial is available within `Dive Into Python
 <http://diveintopython.org/unit_testing/index.html>`_ by Mark Pilgrim.
 
-:mod:`pyramid` provides a number of facilities that make unit and
+:app:`Pyramid` provides a number of facilities that make unit and
 integration tests easier to write.  The facilities become particularly
-useful when your code calls into :mod:`pyramid` -related framework
+useful when your code calls into :app:`Pyramid` -related framework
 functions.
 
 .. index::
@@ -67,7 +67,7 @@ functions.
 Test Set Up and Tear Down
 --------------------------
 
-:mod:`pyramid` uses a "global" (actually :term:`thread local`) data
+:app:`Pyramid` uses a "global" (actually :term:`thread local`) data
 structure to hold on to two items: the current :term:`request` and the
 current :term:`application registry`.  These data structures are
 available via the :func:`pyramid.threadlocal.get_current_request`
@@ -76,7 +76,7 @@ respectively.  See :ref:`threadlocals_chapter` for information about
 these functions and the data structures they return.
 
 If your code uses these ``get_current_*`` functions or calls
-:mod:`pyramid` code which uses ``get_current_*`` functions, you
+:app:`Pyramid` code which uses ``get_current_*`` functions, you
 will need to construct a :term:`Configurator` and call its ``begin``
 method within the ``setUp`` method of your unit test and call the same
 configurator's ``end`` method within the ``tearDown`` method of your
@@ -145,7 +145,7 @@ request you passed into the ``begin`` method.  Otherwise, during
 testing, :func:`pyramid.threadlocal.get_current_request` will
 return ``None``.  We use a "dummy" request implementation supplied by
 :class:`pyramid.testing.DummyRequest` because it's easier to
-construct than a "real" :mod:`pyramid` request object.
+construct than a "real" :app:`Pyramid` request object.
 
 What?
 ~~~~~
@@ -176,7 +176,7 @@ current :term:`application registry`, but typically register a "stub"
 or "dummy" feature in place of the "real" feature that the code would
 call if it was being run normally.
 
-For example, let's imagine you want to unit test a :mod:`pyramid`
+For example, let's imagine you want to unit test a :app:`Pyramid`
 view function.
 
 .. code-block:: python
@@ -191,7 +191,7 @@ view function.
 
 Without invoking any startup code or using the testing API, an attempt
 to run this view function in a unit test will result in an error.
-When a :mod:`pyramid` application starts normally, it will populate
+When a :app:`Pyramid` application starts normally, it will populate
 a :term:`application registry` using :term:`configuration declaration`
 calls made against a :term:`Configurator` (sometimes deferring to the
 application's ``configure.zcml`` :term:`ZCML` file via ``load_zcml``).
@@ -199,9 +199,9 @@ But if this application registry is not created and populated
 (e.g. with an :meth:`pyramid.configuration.Configurator.add_view`
 :term:`configuration declaration` or ``view`` declarations in
 :term:`ZCML`), like when you invoke application code via a unit test,
-:mod:`pyramid` API functions will tend to fail.
+:app:`Pyramid` API functions will tend to fail.
 
-The testing API provided by :mod:`pyramid` allows you to simulate
+The testing API provided by :app:`Pyramid` allows you to simulate
 various application registry registrations for use under a unit
 testing framework without needing to invoke the actual application
 configuration implied by its ``run.py``.  For example, if you wanted
@@ -241,7 +241,7 @@ used the testing API.
            renderer.assert_(say='Yo')
 
 In the above example, we create a ``MyTest`` test case that inherits
-from :mod:`unittest.TestCase`.  If it's in our :mod:`pyramid`
+from :mod:`unittest.TestCase`.  If it's in our :app:`Pyramid`
 application, it will be found when ``setup.py test`` is run.  It has
 two test methods.
 
@@ -257,7 +257,7 @@ hang on to for later.
 We then create a :class:`pyramid.testing.DummyRequest` object which
 simulates a WebOb request object API.  A
 :class:`pyramid.testing.DummyRequest` is a request object that
-requires less setup than a "real" :mod:`pyramid` request.  We call
+requires less setup than a "real" :app:`Pyramid` request.  We call
 the function being tested with the manufactured request.  When the
 function is called,
 :func:`pyramid.chameleon_zpt.render_template_to_response` will call
@@ -289,7 +289,7 @@ sure to use this pattern in your test case's ``setUp`` and
 ``tearDown``; these methods make sure you're using a "fresh"
 :term:`application registry` per test run.
 
-See the :ref:`testing_module` chapter for the entire :mod:`pyramid`
+See the :ref:`testing_module` chapter for the entire :app:`Pyramid`
 -specific testing API.  This chapter describes APIs for registering a
 security policy, registering models at paths, registering event
 listeners, registering views and view permissions, and classes
@@ -306,22 +306,22 @@ See also the various methods of the :term:`Configurator` documented in
 Creating Integration Tests
 --------------------------
 
-In :mod:`pyramid`, a *unit test* typically relies on "mock" or
+In :app:`Pyramid`, a *unit test* typically relies on "mock" or
 "dummy" implementations to give the code under test only enough
 context to run.
 
 "Integration testing" implies another sort of testing.  In the context
-of a :mod:`pyramid`, integration test, the test logic tests the
+of a :app:`Pyramid`, integration test, the test logic tests the
 functionality of some code *and* its integration with the rest of the
-:mod:`pyramid` framework.
+:app:`Pyramid` framework.
 
-In :mod:`pyramid` applications that use :term:`ZCML`, you can
+In :app:`Pyramid` applications that use :term:`ZCML`, you can
 create an integration test by *loading its ZCML* in the test's setup
-code.  This causes the entire :mod:`pyramid` environment to be set
+code.  This causes the entire :app:`Pyramid` environment to be set
 up and torn down as if your application was running "for real".  This
 is a heavy-hammer way of making sure that your tests have enough
 context to run properly, and it tests your code's integration with the
-rest of :mod:`pyramid`.
+rest of :app:`Pyramid`.
 
 Let's demonstrate this by showing an integration test for a view.  The
 below test assumes that your application's package name is ``myapp``,
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index 7fd94e89e..87efddfad 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -6,7 +6,7 @@
 URL Dispatch
 ============
 
-The URL dispatch feature of :mod:`pyramid` allows you to either
+The URL dispatch feature of :app:`Pyramid` allows you to either
 augment or replace :term:`traversal` as a :term:`context finding`
 mechanism, allowing URL pattern matching to have the "first crack" at
 resolving a given URL to :term:`context` and :term:`view name`.
@@ -15,14 +15,14 @@ Although it is a "context-finding" mechanism, ironically, using URL
 dispatch exclusively allows you to avoid thinking about your
 application in terms of "contexts" and "view names" entirely.
 
-Many applications don't need :mod:`pyramid` features -- such as
+Many applications don't need :app:`Pyramid` features -- such as
 declarative security via an :term:`authorization policy` -- that
 benefit from having any visible separation between :term:`context
 finding` and :term:`view lookup`.  To this end, URL dispatch provides
 a handy syntax that allows you to effectively map URLs *directly* to
 :term:`view` code in such a way that you needn't think about your
 application in terms of "context finding" at all.  This makes developing
-a :mod:`pyramid` application seem more like developing an
+a :app:`Pyramid` application seem more like developing an
 application in a system that is "context-free", such as :term:`Pylons`
 or :term:`Django`.
 
@@ -49,20 +49,20 @@ High-Level Operational Overview
 -------------------------------
 
 If route configuration is present in an application, the
-:mod:`pyramid` :term:`Router` checks every incoming request against
+:app:`Pyramid` :term:`Router` checks every incoming request against
 an ordered set of URL matching patterns present in a *route map*.
 
 If any route pattern matches the information in the :term:`request`
-provided to :mod:`pyramid`, a route-specific :term:`context` and
+provided to :app:`Pyramid`, a route-specific :term:`context` and
 :term:`view name` will be generated.  In this circumstance,
-:mod:`pyramid` will shortcut :term:`traversal`, and will invoke
+:app:`Pyramid` will shortcut :term:`traversal`, and will invoke
 :term:`view lookup` using the context and view name generated by URL
 dispatch.  If the matched route names a :term:`view callable` in its
 configuration, that view callable will be invoked when view lookup is
 performed.
 
 However, if no route pattern matches the information in the
-:term:`request` provided to :mod:`pyramid`, it will fail over to
+:term:`request` provided to :app:`Pyramid`, it will fail over to
 using :term:`traversal` to perform context finding and view lookup.
 
 Route Configuration
@@ -71,7 +71,7 @@ Route Configuration
 :term:`Route configuration` is the act of adding a new :term:`route`
 to an application.  A route has a *pattern*, representing a pattern
 meant to match against the ``PATH_INFO`` portion of a URL, and a
-*name*, which is used by developers within a :mod:`pyramid`
+*name*, which is used by developers within a :app:`Pyramid`
 application to uniquely identify a particular route when generating a
 URL.  It also optionally has a ``factory``, a set of :term:`route
 predicate` parameters, and a set of :term:`view` parameters.
@@ -153,7 +153,7 @@ Route View Callable Registration and Lookup Details
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
 When a ``view`` attribute is attached to a route configuration,
-:mod:`pyramid` ensures that a :term:`view configuration` is
+:app:`Pyramid` ensures that a :term:`view configuration` is
 registered that will always be found when the route pattern is matched
 during a request.  To do so:
 
@@ -175,8 +175,8 @@ during a request.  To do so:
   to service requests that match the route pattern.
 
 In this way, we supply a shortcut to the developer.  Under the hood,
-:mod:`pyramid` still consumes the :term:`context finding` and
-:term:`view lookup` subsystems provided by :mod:`pyramid`, but in a
+:app:`Pyramid` still consumes the :term:`context finding` and
+:term:`view lookup` subsystems provided by :app:`Pyramid`, but in a
 way which does not require that a developer understand either of them
 if he doesn't want or need to.  It also means that we can allow a
 developer to combine :term:`URL dispatch` and :term:`traversal` in
@@ -190,7 +190,7 @@ various exceptional cases as documented in :ref:`hybrid_chapter`.
 Route Pattern Syntax
 ~~~~~~~~~~~~~~~~~~~~
 
-The syntax of the pattern matching language used by :mod:`pyramid`
+The syntax of the pattern matching language used by :app:`Pyramid`
 URL dispatch in the *pattern* argument is straightforward; it is close
 to that of the :term:`Routes` system used by :term:`Pylons`.
 
@@ -391,7 +391,7 @@ possible to supply a different :term:`context` object to the view
 related to each particular route.
 
 Supplying a different context for each route is useful when you're
-trying to use a :mod:`pyramid` :term:`authorization policy` to
+trying to use a :app:`Pyramid` :term:`authorization policy` to
 provide declarative "context-sensitive" security checks; each context
 can maintain a separate :term:`ACL`, as in
 :ref:`using_security_with_urldispatch`.  It is also useful when you
@@ -425,7 +425,7 @@ represent neither predicates nor view configuration information.
 ``factory``
   A Python object (often a function or a class) or a :term:`dotted
   Python name` to such an object that will generate a
-  :mod:`pyramid` :term:`context` object when this route
+  :app:`Pyramid` :term:`context` object when this route
   matches. For example, ``mypackage.models.MyFactoryClass``.  If this
   argument is not specified, the traversal root factory will be used.
 
@@ -737,9 +737,9 @@ The main purpose of route configuration is to match (or not match)
 the ``PATH_INFO`` present in the WSGI environment provided during a
 request against a URL path pattern.
 
-The way that :mod:`pyramid` does this is very simple.  When a
+The way that :app:`Pyramid` does this is very simple.  When a
 request enters the system, for each route configuration declaration
-present in the system, :mod:`pyramid` checks the ``PATH_INFO``
+present in the system, :app:`Pyramid` checks the ``PATH_INFO``
 against the pattern declared.
 
 If any route matches, the route matching process stops.  The
@@ -762,7 +762,7 @@ skipped and route matching continues through the ordered set of
 routes.
 
 If no route matches after all route patterns are exhausted,
-:mod:`pyramid` falls back to :term:`traversal` to do :term:`context
+:app:`Pyramid` falls back to :term:`traversal` to do :term:`context
 finding` and :term:`view lookup`.
 
 .. index::
@@ -865,7 +865,7 @@ might add to your application:
    config.add_route('user', 'users/:user', view='mypackage.views.user_view')
    config.add_route('tag', 'tags/:tags', view='mypackage.views.tag_view')
 
-The above configuration will allow :mod:`pyramid` to service URLs
+The above configuration will allow :app:`Pyramid` to service URLs
 in these forms:
 
 .. code-block:: text
@@ -1064,10 +1064,10 @@ general description of how to configure a not found view.
 Custom Not Found View With Slash Appended Routes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-There can only be one :term:`Not Found view` in any :mod:`pyramid`
+There can only be one :term:`Not Found view` in any :app:`Pyramid`
 application.  Even if you use
 :func:`pyramid.view.append_slash_notfound_view` as the Not Found
-view, :mod:`pyramid` still must generate a ``404 Not Found``
+view, :app:`Pyramid` still must generate a ``404 Not Found``
 response when it cannot redirect to a slash-appended URL; this not
 found response will be visible to site users.
 
@@ -1115,7 +1115,7 @@ Instead of putting this cleanup logic in the root factory, however,
 you can cause a subscriber to be fired when a new request is detected;
 the subscriber can do this work.
 
-For example, let's say you have a ``mypackage`` :mod:`pyramid`
+For example, let's say you have a ``mypackage`` :app:`Pyramid`
 application package that uses SQLAlchemy, and you'd like the current
 SQLAlchemy database session to be removed after each request.  Put the
 following in the ``mypackage.run`` module:
@@ -1151,7 +1151,7 @@ every request).
 .. note:: This is only an example.  In particular, it is not necessary
    to cause ``DBSession.remove`` to be called as the result of an
    event listener in an application generated from any
-   :mod:`pyramid` paster template, because these all use the
+   :app:`Pyramid` paster template, because these all use the
    ``repoze.tm2`` middleware.  The cleanup done by
    ``DBSession.remove`` is unnecessary when ``repoze.tm2`` middleware
    is in the WSGI pipeline.
@@ -1161,10 +1161,10 @@ every request).
 
 .. _using_security_with_urldispatch:
 
-Using :mod:`pyramid` Security With URL Dispatch
+Using :app:`Pyramid` Security With URL Dispatch
 --------------------------------------------------
 
-:mod:`pyramid` provides its own security framework which consults an
+:app:`Pyramid` provides its own security framework which consults an
 :term:`authorization policy` before allowing any application code to
 be called.  This framework operates in terms of an access control
 list, which is stored as an ``__acl__`` attribute of a context object.
@@ -1186,7 +1186,7 @@ Such a ``factory`` might look like so:
               self.__acl__ = [ (Allow, 'editor', 'view') ]
 
 If the route ``archives/:article`` is matched, and the article number
-is ``1``, :mod:`pyramid` will generate an ``Article``
+is ``1``, :app:`Pyramid` will generate an ``Article``
 :term:`context` with an ACL on it that allows the ``editor`` principal
 the ``view`` permission.  Obviously you can do more generic things
 than inspect the routes match dict to see if the ``article`` argument
@@ -1194,11 +1194,11 @@ matches a particular string; our sample ``Article`` factory class is
 not very ambitious.
 
 .. note:: See :ref:`security_chapter` for more information about
-   :mod:`pyramid` security and ACLs.
+   :app:`Pyramid` security and ACLs.
 
 References
 ----------
 
 A tutorial showing how :term:`URL dispatch` can be used to create a
-:mod:`pyramid` application exists in :ref:`bfg_sql_wiki_tutorial`.
+:app:`Pyramid` application exists in :ref:`bfg_sql_wiki_tutorial`.
 
diff --git a/docs/narr/vhosting.rst b/docs/narr/vhosting.rst
index 69ef4b72f..0f0fd0d4d 100644
--- a/docs/narr/vhosting.rst
+++ b/docs/narr/vhosting.rst
@@ -6,19 +6,19 @@
 Virtual Hosting
 ===============
 
-"Virtual hosting" is, loosely, the act of serving a :mod:`pyramid`
-application or a portion of a :mod:`pyramid` application under a
+"Virtual hosting" is, loosely, the act of serving a :app:`Pyramid`
+application or a portion of a :app:`Pyramid` application under a
 URL space that it does not "naturally" inhabit.
 
-:mod:`pyramid` provides facilities for serving an application under
+:app:`Pyramid` provides facilities for serving an application under
 a URL "prefix", as well as serving a *portion* of a :term:`traversal`
 based application under a root URL.
 
 Hosting an Application Under a URL Prefix
 -----------------------------------------
 
-:mod:`pyramid` supports a common form of virtual hosting whereby you
-can host a :mod:`pyramid` application as a "subset" of some other site
+:app:`Pyramid` supports a common form of virtual hosting whereby you
+can host a :app:`Pyramid` application as a "subset" of some other site
 (e.g. under ``http://example.com/mypyramidapplication/`` as opposed to
 under ``http://example.com/``).
 
@@ -29,8 +29,8 @@ by Paste's `urlmap <http://pythonpaste.org/modules/urlmap.html>`_
 hosting translation for you "under the hood".
 
 If you use the ``urlmap`` composite application "in front" of a
-:mod:`pyramid` application or if you use :term:`mod_wsgi` to serve
-up a :mod:`pyramid` application, nothing special needs to be done
+:app:`Pyramid` application or if you use :term:`mod_wsgi` to serve
+up a :app:`Pyramid` application, nothing special needs to be done
 within the application for URLs to be generated that contain a
 prefix. :mod:`paste.urlmap` and :term:`mod_wsgi` manipulate the
 :term:`WSGI` environment in such a way that the ``PATH_INFO`` and
@@ -48,7 +48,7 @@ a ``urlmap`` composite.
   use = egg:Paste#urlmap
   /pyramidapp = mypyramidapp
 
-This "roots" the :mod:`pyramid` application at the prefix
+This "roots" the :app:`Pyramid` application at the prefix
 ``/pyramidapp`` and serves up the composite as the "main" application
 in the file.
 
@@ -71,7 +71,7 @@ work for you:
 
    WSGIScriptAlias /pyramidapp /Users/chrism/projects/modwsgi/env/pyramid.wsgi
 
-In the above configuration, we root a :mod:`pyramid` application at
+In the above configuration, we root a :app:`Pyramid` application at
 ``/pyramidapp`` within the Apache configuration.
 
 .. index::
@@ -80,12 +80,12 @@ In the above configuration, we root a :mod:`pyramid` application at
 Virtual Root Support
 --------------------
 
-:mod:`pyramid` also supports "virtual roots", which can be used in
+:app:`Pyramid` also supports "virtual roots", which can be used in
 :term:`traversal` -based (but not :term:`URL dispatch` -based)
 applications.
 
 Virtual root support is useful when you'd like to host some model in a
-:mod:`pyramid` object graph as an application under a URL pathname
+:app:`Pyramid` object graph as an application under a URL pathname
 that does not include the model path itself.  For example, you might
 want to serve the object at the traversal path ``/cms`` as an
 application reachable via ``http://example.com/`` (as opposed to
@@ -122,7 +122,7 @@ is below:
    <http://httpd.apache.org/docs/2.2/mod/mod_headers.html>`_ module be
    available in the Apache environment you're using.
 
-For a :mod:`pyramid` application running under :term:`mod_wsgi`,
+For a :app:`Pyramid` application running under :term:`mod_wsgi`,
 the same can be achieved using ``SetEnv``:
 
 .. code-block:: apache
@@ -144,5 +144,5 @@ returns the virtual root object (or the physical root object if no
 virtual root has been specified).
 
 :ref:`modwsgi_tutorial` has detailed information about using
-:term:`mod_wsgi` to serve :mod:`pyramid` applications.
+:term:`mod_wsgi` to serve :app:`Pyramid` applications.
 
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index ebd690330..c82dd2cb2 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -3,7 +3,7 @@
 Views
 =====
 
-The primary job of any :mod:`pyramid` application is is to find and
+The primary job of any :app:`Pyramid` application is is to find and
 invoke a :term:`view callable` when a :term:`request` reaches the
 application.  View callables are bits of code written by you -- the
 application developer -- which do something interesting in response to
@@ -11,7 +11,7 @@ a request made to your application.
 
 .. note:: 
 
-   A :mod:`pyramid` :term:`view callable` is often referred to in
+   A :app:`Pyramid` :term:`view callable` is often referred to in
    conversational shorthand as a :term:`view`.  In this documentation,
    however, we need to use less ambiguous terminology because there
    are significant differences between view *configuration*, the code
@@ -39,12 +39,12 @@ View Callables
 --------------
 
 No matter how a view callable is eventually found, all view callables
-used by :mod:`pyramid` must be constructed in the same way, and
+used by :app:`Pyramid` must be constructed in the same way, and
 must return the same kind of return value.
 
 Most view callables accept a single argument named ``request``.  This argument
-represents a :mod:`pyramid` :term:`Request` object.  A request object
-encapsulates a WSGI environment as represented to :mod:`pyramid` by the
+represents a :app:`Pyramid` :term:`Request` object.  A request object
+encapsulates a WSGI environment as represented to :app:`Pyramid` by the
 upstream :term:`WSGI` server.
 
 A view callable may always return a :mod:`Pyramid` :term:`Response` object
@@ -150,7 +150,7 @@ context
   will be a :term:`model` object.
 
 request
-  A :mod:`pyramid` Request object representing the current WSGI
+  A :app:`Pyramid` Request object representing the current WSGI
   request.
 
 The following types work as view callables in this style:
@@ -211,7 +211,7 @@ has access to the context via ``request.context``.
 View Callable Responses
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-A view callable may always return an object that implements the :mod:`pyramid`
+A view callable may always return an object that implements the :app:`Pyramid`
 :term:`Response` interface.  The easiest way to return something that
 implements the :term:`Response` interface is to return a
 :class:`pyramid.response.Response` object instance directly.  For example:
@@ -225,7 +225,7 @@ implements the :term:`Response` interface is to return a
        return Response('OK')
 
 You don't need to always use :class:`pyramid.response.Response` to represent a
-response.  :mod:`pyramid` provides a range of different "exception" classes
+response.  :app:`Pyramid` provides a range of different "exception" classes
 which can act as response objects too.  For example, an instance of the class
 :class:`pyramid.httpexceptions.HTTPFound` is also a valid response object (see
 :ref:`http_redirect`).  A view can actually return any object that has the
@@ -249,7 +249,7 @@ app_iter
 
 Furthermore, a view needn't *always* return a Response object.  If a view
 happens to return something which does not implement the Pyramid Response
-interface, :mod:`pyramid` will attempt to use a :term:`renderer` to construct a
+interface, :app:`Pyramid` will attempt to use a :term:`renderer` to construct a
 response.  For example:
 
 .. code-block:: python
@@ -350,7 +350,7 @@ response.
 If the :term:`view callable` associated with a :term:`view configuration`
 returns a Response object directly (an object with the attributes ``status``,
 ``headerlist`` and ``app_iter``), any renderer associated with the view
-configuration is ignored, and the response is passed back to :mod:`pyramid`
+configuration is ignored, and the response is passed back to :app:`Pyramid`
 unmolested.  For example, if your view callable returns an instance of the
 :class:`pyramid.httpexceptions.HTTPFound` class as a response, no renderer will
 be employed.
@@ -379,7 +379,7 @@ Additional renderers can be added to the system as necessary (see
 Built-In Renderers
 ~~~~~~~~~~~~~~~~~~
 
-Several built-in "renderers" exist in :mod:`pyramid`.  These
+Several built-in "renderers" exist in :app:`Pyramid`.  These
 renderers can be used in the ``renderer`` attribute of view
 configurations.
 
@@ -621,7 +621,7 @@ Varying Attributes of Rendered Responses
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Before a response that is constructed as the result of the use of a
-:term:`renderer` is returned to :mod:`pyramid`, several attributes
+:term:`renderer` is returned to :app:`Pyramid`, several attributes
 of the request are examined which have the potential to influence
 response behavior.
 
@@ -676,7 +676,7 @@ documentation in :ref:`request_module`.
 Adding and Overriding Renderers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-New templating systems and serializers can be associated with :mod:`pyramid`
+New templating systems and serializers can be associated with :app:`Pyramid`
 renderer names.  To this end, configuration declarations can be made which
 override an existing :term:`renderer factory` and which add a new renderer
 factory.
@@ -845,7 +845,7 @@ extension for the same kinds of templates.  For example, to associate the
 
    config.add_renderer('.zpt', 'pyramid.chameleon_zpt.renderer_factory')
 
-After you do this, :mod:`pyramid` will treat templates ending in both the
+After you do this, :app:`Pyramid` will treat templates ending in both the
 ``.pt`` and ``.zpt`` filename extensions as Chameleon ZPT templates.
 
 To override the default mapping in which files with a ``.pt`` extension are
@@ -879,11 +879,11 @@ Using Special Exceptions In View Callables
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Usually when a Python exception is raised within a view callable,
-:mod:`pyramid` allows the exception to propagate all the way out to
+:app:`Pyramid` allows the exception to propagate all the way out to
 the :term:`WSGI` server which invoked the application.
 
 However, for convenience, two special exceptions exist which are
-always handled by :mod:`pyramid` itself.  These are
+always handled by :app:`Pyramid` itself.  These are
 :exc:`pyramid.exceptions.NotFound` and
 :exc:`pyramid.exceptions.Forbidden`.  Both are exception classes
 which accept a single positional constructor argument: a ``message``.
@@ -897,7 +897,7 @@ the result of the :term:`Forbidden View` will be returned to the user
 agent which performed the request.
 
 In all cases, the message provided to the exception constructor is
-made available to the view which :mod:`pyramid` invokes as
+made available to the view which :app:`Pyramid` invokes as
 ``request.exception.args[0]``.
 
 .. index::
@@ -916,7 +916,7 @@ specialized views as described in
 developers to convert arbitrary exceptions to responses.
 
 To register a view that should be called whenever a particular
-exception is raised from with :mod:`pyramid` view code, use the
+exception is raised from with :app:`Pyramid` view code, use the
 exception class or one of its superclasses as the ``context`` of a
 view configuration which points at a view callable you'd like to
 generate a response.
@@ -999,23 +999,23 @@ Handling Form Submissions in View Callables (Unicode and Character Set Issues)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Most web applications need to accept form submissions from web
-browsers and various other clients.  In :mod:`pyramid`, form
+browsers and various other clients.  In :app:`Pyramid`, form
 submission handling logic is always part of a :term:`view`.  For a
 general overview of how to handle form submission data using the
 :term:`WebOb` API, see :ref:`webob_chapter` and `"Query and POST
 variables" within the WebOb documentation
 <http://pythonpaste.org/webob/reference.html#query-post-variables>`_.
-:mod:`pyramid` defers to WebOb for its request and response
+:app:`Pyramid` defers to WebOb for its request and response
 implementations, and handling form submission data is a property of
 the request implementation.  Understanding WebOb's request API is the
 key to understanding how to process form submission data.
 
 There are some defaults that you need to be aware of when trying to handle form
-submission data in a :mod:`pyramid` view.  Because having high-order
+submission data in a :app:`Pyramid` view.  Because having high-order
 (non-ASCII) characters in data contained within form submissions is exceedingly
 common, and because the UTF-8 encoding is the most common encoding used on the
 web for non-ASCII character data, and because working and storing Unicode
-values is much saner than working with and storing bytestrings, :mod:`pyramid`
+values is much saner than working with and storing bytestrings, :app:`Pyramid`
 configures the :term:`WebOb` request machinery to attempt to decode form
 submission values into Unicode from the UTF-8 character set implicitly.  This
 implicit decoding happens when view code obtains form field values via the
@@ -1023,7 +1023,7 @@ implicit decoding happens when view code obtains form field values via the
 :ref:`request_module` for details about these APIs).
 
 For example, let's assume that the following form page is served up to
-a browser client, and its ``action`` points at some :mod:`pyramid`
+a browser client, and its ``action`` points at some :app:`Pyramid`
 view code:
 
 .. code-block:: xml
@@ -1044,7 +1044,7 @@ view code:
      </form>
    </html>
 
-The ``myview`` view code in the :mod:`pyramid` application *must*
+The ``myview`` view code in the :app:`Pyramid` application *must*
 expect that the values returned by ``request.params`` will be of type
 ``unicode``, as opposed to type ``str``. The following will work to
 accept a form post from the above form:
@@ -1070,7 +1070,7 @@ decode already-decoded (``unicode``) values obtained from
        lastname = request.params['lastname'].decode('utf-8')
 
 For implicit decoding to work reliably, you should ensure that every form you
-render that posts to a :mod:`pyramid` view is rendered via a response that has
+render that posts to a :app:`Pyramid` view is rendered via a response that has
 a ``;charset=UTF-8`` in its ``Content-Type`` header; or, as in the form above,
 with a ``meta http-equiv`` tag that implies that the charset is UTF-8 within
 the HTML ``head`` of the page containing the form.  This must be done
@@ -1098,7 +1098,7 @@ response object, you will need to ensure you do this yourself.
 
 .. note:: Only the *values* of request params obtained via
    ``request.params``, ``request.GET`` or ``request.POST`` are decoded
-   to Unicode objects implicitly in the :mod:`pyramid` default
+   to Unicode objects implicitly in the :app:`Pyramid` default
    configuration.  The keys are still strings.
 
 .. index::
@@ -1110,7 +1110,7 @@ View Configuration: Mapping a Context to a View
 -----------------------------------------------
 
 A developer makes a :term:`view callable` available for use within a
-:mod:`pyramid` application via :term:`view configuration`.  A view
+:app:`Pyramid` application via :term:`view configuration`.  A view
 configuration associates a view callable with a set of statements
 about the set of circumstances which must be true for the view
 callable to be invoked.
@@ -1220,7 +1220,7 @@ Non-Predicate Arguments
 
   The ``renderer`` attribute is optional.  If it is not defined, the
   "null" renderer is assumed (no rendering is performed and the value
-  is passed back to the upstream :mod:`pyramid` machinery
+  is passed back to the upstream :app:`Pyramid` machinery
   unmolested).  Note that if the view callable itself returns a
   :term:`response` (see :ref:`the_response`), the specified renderer
   implementation is never called.
@@ -1433,13 +1433,13 @@ Usage of the ``view_config`` decorator is a form of :term:`declarative
 configuration`, like ZCML, but in decorator form.
 :class:`pyramid.view.view_config` can be used to associate :term:`view
 configuration` information -- as done via the equivalent imperative code or
-ZCML -- with a function that acts as a :mod:`pyramid` view callable.  All
+ZCML -- with a function that acts as a :app:`Pyramid` view callable.  All
 arguments to the :meth:`pyramid.configuration.Configurator.add_view` method
 (save for the ``view`` argument) are available in decorator form and mean
 precisely the same thing.
 
 An example of the :class:`pyramid.view.view_config` decorator might
-reside in a :mod:`pyramid` application module ``views.py``:
+reside in a :app:`Pyramid` application module ``views.py``:
 
 .. ignore-next-block
 .. code-block:: python
@@ -1483,7 +1483,7 @@ requests with any request method / request type / request param /
 route name / containment.
 
 The mere existence of a ``@view_config`` decorator doesn't suffice to perform
-view configuration.  To make :mod:`pyramid` process your
+view configuration.  To make :app:`Pyramid` process your
 :class:`pyramid.view.view_config` declarations, you *must* do use the
 ``scan`` method of a :class:`pyramid.configuration.Configurator`:
 
@@ -1786,7 +1786,7 @@ will be returned to the client as per :ref:`protecting_views`.
 View Lookup and Invocation
 --------------------------
 
-:term:`View lookup` is the :mod:`pyramid` subsystem responsible for
+:term:`View lookup` is the :app:`Pyramid` subsystem responsible for
 finding an invoking a :term:`view callable`.  The view lookup
 subsystem is passed a :term:`context`, a :term:`view name`, and the
 :term:`request` object.  These three bits of information are referred
@@ -1807,7 +1807,7 @@ For any given request, a view with five predicates will always be
 found and evaluated before a view with two, for example.  All
 predicates must match for the associated view to be called.
 
-This does not mean however, that :mod:`pyramid` "stops looking"
+This does not mean however, that :app:`Pyramid` "stops looking"
 when it finds a view registration with predicates that don't match.
 If one set of view predicates does not match, the "next most specific"
 view (if any) view is consulted for predicates, and so on, until a
@@ -1816,7 +1816,7 @@ first view with a set of predicates all of which match the request
 environment will be invoked.
 
 If no view can be found which has predicates which allow it to be
-matched up with the request, :mod:`pyramid` will return an error to
+matched up with the request, :app:`Pyramid` will return an error to
 the user's browser, representing a "not found" (404) page.  See
 :ref:`changing_the_notfound_view` for more information about changing
 the default notfound view.
diff --git a/docs/narr/webob.rst b/docs/narr/webob.rst
index b496db41e..17827fac9 100644
--- a/docs/narr/webob.rst
+++ b/docs/narr/webob.rst
@@ -10,17 +10,17 @@ Request and Response Objects
 .. note:: This chapter is adapted from a portion of the :term:`WebOb`
    documentation, originally written by Ian Bicking.
 
-:mod:`pyramid` uses the :term:`WebOb` package to supply
+:app:`Pyramid` uses the :term:`WebOb` package to supply
 :term:`request` and :term:`response` object implementations.  The
-:term:`request` object that is passed to a :mod:`pyramid`
+:term:`request` object that is passed to a :app:`Pyramid`
 :term:`view` is an instance of the :class:`pyramid.request.Request`
 class, which is a subclass of :class:`webob.Request`.  The
-:term:`response` returned from a :mod:`pyramid` :term:`view`
+:term:`response` returned from a :app:`Pyramid` :term:`view`
 :term:`renderer` is an instance of the :mod:`webob.Response` class.
 Users can also return an instance of :mod:`webob.Response` directly
 from a view as necessary.
 
-WebOb is a project separate from :mod:`pyramid` with a separate set
+WebOb is a project separate from :app:`Pyramid` with a separate set
 of authors and a fully separate `set of documentation
 <http://pythonpaste.org/webob/>`_.
 
@@ -31,7 +31,7 @@ environment and response status/headers/app_iter (body).
 WebOb request and response objects provide many conveniences for
 parsing WSGI requests and forming WSGI responses.  WebOb is a nice way
 to represent "raw" WSGI requests and responses; however, we won't
-cover that use case in this document, as users of :mod:`pyramid`
+cover that use case in this document, as users of :app:`Pyramid`
 don't typically need to use the WSGI-related features of WebOb
 directly.  The `reference documentation
 <http://pythonpaste.org/webob/reference.html>`_ shows many examples of
@@ -98,7 +98,7 @@ instance, ``req.if_modified_since`` returns a `datetime
 <http://python.org/doc/current/lib/datetime-datetime.html>`_ object
 (or None if the header is was not provided).
 
-.. note:: Full API documentation for the :mod:`pyramid` request
+.. note:: Full API documentation for the :app:`Pyramid` request
    object is available in :ref:`request_module`.
 
 .. index::
@@ -106,10 +106,10 @@ instance, ``req.if_modified_since`` returns a `datetime
 
 .. _special_request_attributes:
 
-Special Attributes Added to the Request by :mod:`pyramid`
+Special Attributes Added to the Request by :app:`Pyramid`
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-In addition to the standard :term:`WebOb` attributes, :mod:`pyramid`
+In addition to the standard :term:`WebOb` attributes, :app:`Pyramid`
 adds special attributes to every request: ``context``, ``registry``,
 ``root``, ``subpath``, ``traversed``, ``view_name``, ``virtual_root``
 , ``virtual_root_path``, ``session``, and ``tmpl_context``.  These
@@ -196,7 +196,7 @@ More detail about the request object API is available in:
 - The `WebOb documentation <http://pythonpaste.org/webob>`_ .  All
   methods and attributes of a ``webob.Request`` documented within the
   WebOb documentation will work against request objects created by
-  :mod:`pyramid`.
+  :app:`Pyramid`.
 
 .. index::
    single: response object
@@ -204,7 +204,7 @@ More detail about the request object API is available in:
 Response
 ~~~~~~~~
 
-The :mod:`pyramid` response object can be imported as
+The :app:`Pyramid` response object can be imported as
 :class:`pyramid.response.Response`.  This import location is merely a facade
 for its original location: ``webob.Response``.
 
@@ -305,7 +305,7 @@ Exception Responses
 To facilitate error responses like ``404 Not Found``, the module
 :mod:`webob.exc` contains classes for each kind of error response.  These
 include boring but appropriate error bodies.  The exceptions exposed by this
-module, when used under :mod:`pyramid`, should be imported from the
+module, when used under :app:`Pyramid`, should be imported from the
 :mod:`pyramid.httpexceptions` "facade" module.  This import location is merely
 a facade for the original location of these exceptions: ``webob.exc``.
 
diff --git a/docs/narr/zca.rst b/docs/narr/zca.rst
index b558580b5..cf05f39ed 100644
--- a/docs/narr/zca.rst
+++ b/docs/narr/zca.rst
@@ -8,10 +8,10 @@
 
 .. _zca_chapter:
 
-Using the Zope Component Architecture in :mod:`pyramid`
+Using the Zope Component Architecture in :app:`Pyramid`
 ==========================================================
 
-Under the hood, :mod:`pyramid` uses a :term:`Zope Component
+Under the hood, :app:`Pyramid` uses a :term:`Zope Component
 Architecture` component registry as its :term:`application registry`.
 The Zope Component Architecture is referred to colloquially as the
 "ZCA."
@@ -36,16 +36,16 @@ API is used by a developer, the conceptual load on a casual reader of
 code is high.
 
 While the ZCA is an excellent tool with which to build a *framework*
-such as :mod:`pyramid`, it is not always the best tool with which
+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, :mod:`pyramid` tends to hide the the presence
+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 :mod:`pyramid` application; its use is effectively
+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
-:mod:`pyramid` application; :mod:`pyramid` makes this possible.
+:app:`Pyramid` application; :mod:`pyramid` makes this possible.
 
 .. index::
    single: get_current_registry
@@ -53,7 +53,7 @@ applications often still wish to use the ZCA while building a
    single: getSiteManager
    single: ZCA global API
 
-Using the ZCA Global API in a :mod:`pyramid` Application
+Using the ZCA Global API in a :app:`Pyramid` Application
 -----------------------------------------------------------
 
 :term:`Zope` uses a single ZCA registry -- the "global" ZCA registry
@@ -72,24 +72,24 @@ process.
 
 Most production Zope applications are relatively large, making it
 impractical due to memory constraints to run more than one Zope
-application per Python process.  However, a :mod:`pyramid`
+application per Python process.  However, a :app:`Pyramid`
 application may be very small and consume very little memory, so it's
 a reasonable goal to be able to run more than one BFG application per
 process.
 
-In order to make it possible to run more than one :mod:`pyramid`
-application in a single process, :mod:`pyramid` defaults to using a
+In order to make it possible to run more than one :app:`Pyramid`
+application in a single process, :app:`Pyramid` defaults to using a
 separate ZCA registry *per application*.
 
 While this services a reasonable goal, it causes some issues when
 trying to use patterns which you might use to build a typical
-:term:`Zope` application to build a :mod:`pyramid` application.
+:term:`Zope` application to build a :app:`Pyramid` application.
 Without special help, ZCA "global" APIs such as
 ``zope.component.getUtility`` and ``zope.component.getSiteManager``
 will use the ZCA "global" registry.  Therefore, these APIs
-will appear to fail when used in a :mod:`pyramid` application,
+will appear to fail when used in a :app:`Pyramid` application,
 because they'll be consulting the ZCA global registry rather than the
-component registry associated with your :mod:`pyramid` application.
+component registry associated with your :app:`Pyramid` application.
 
 There are three ways to fix this: by disusing the ZCA global API
 entirely, by using
@@ -123,18 +123,18 @@ but it largely mirrors the "global" API almost exactly.
 
 If you are willing to disuse the "global" ZCA APIs and use the method
 interface of a registry instead, you need only know how to obtain the
-:mod:`pyramid` component registry.
+:app:`Pyramid` component registry.
 
 There are two ways of doing so:
 
 - use the :func:`pyramid.threadlocal.get_current_registry`
-  function within :mod:`pyramid` view or model code.  This will
-  always return the "current" :mod:`pyramid` application registry.
+  function within :app:`Pyramid` view or model code.  This will
+  always return the "current" :app:`Pyramid` application registry.
 
 - use the attribute of the :term:`request` object named ``registry``
-  in your :mod:`pyramid` view code, eg. ``request.registry``.  This
+  in your :app:`Pyramid` view code, eg. ``request.registry``.  This
   is the ZCA component registry related to the running
-  :mod:`pyramid` application.
+  :app:`Pyramid` application.
 
 See :ref:`threadlocals_chapter` for more information about
 :func:`pyramid.threadlocal.get_current_registry`.
@@ -147,7 +147,7 @@ See :ref:`threadlocals_chapter` for more information about
 Enabling the ZCA Global API by Using ``hook_zca``
 +++++++++++++++++++++++++++++++++++++++++++++++++
 
-Consider the following bit of idiomatic :mod:`pyramid` startup code:
+Consider the following bit of idiomatic :app:`Pyramid` startup code:
 
 .. code-block:: python
    :linenos:
@@ -213,14 +213,14 @@ is that an analogue of the following code is executed:
    from pyramid.threadlocal import get_current_registry
    getSiteManager.sethook(get_current_registry)
 
-This causes the ZCA global API to start using the :mod:`pyramid`
-application registry in threads which are running a :mod:`pyramid`
+This causes the ZCA global API to start using the :app:`Pyramid`
+application registry in threads which are running a :app:`Pyramid`
 request.
 
 Calling ``hook_zca`` is usually sufficient to "fix" the problem of
-being able to use the global ZCA API within a :mod:`pyramid`
+being able to use the global ZCA API within a :app:`Pyramid`
 application.  However, it also means that a Zope application that is
-running in the same process may start using the :mod:`pyramid`
+running in the same process may start using the :app:`Pyramid`
 global registry instead of the Zope global registry, effectively
 inverting the original problem.  In such a case, follow the steps in
 the next section, :ref:`using_the_zca_global_registry`.
@@ -235,7 +235,7 @@ the next section, :ref:`using_the_zca_global_registry`.
 Enabling the ZCA Global API by Using The ZCA Global Registry
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-You can tell your :mod:`pyramid` application to use the ZCA global
+You can tell your :app:`Pyramid` application to use the ZCA global
 registry at startup time instead of constructing a new one:
 
 .. code-block:: python
@@ -262,7 +262,7 @@ registry with BFG-specific registrations; this is code that is
 normally executed when a registry is constructed rather than created,
 but we must call it "by hand" when we pass an explicit registry.
 
-At this point, :mod:`pyramid` will use the ZCA global registry
+At this point, :app:`Pyramid` will use the ZCA global registry
 rather than creating a new application-specific registry; since by
 default the ZCA global API will use this registry, things will work as
 you might expect a Zope app to when you use the global ZCA API.
@@ -280,7 +280,7 @@ Some :term:`Zope` and third-party :term:`ZCML` directives use the
 they should actually be calling ``zope.component.getSiteManager``.
 
 ``zope.component.getSiteManager`` can be overridden by
-:mod:`pyramid` via
+:app:`Pyramid` via
 :meth:`pyramid.configuration.Configurator.hook_zca`, while
 ``zope.component.getGlobalSiteManager`` cannot.  Directives that use
 ``zope.component.getGlobalSiteManager`` are effectively broken; no
@@ -288,7 +288,7 @@ ZCML directive should be using this function to find a registry to
 populate.
 
 You cannot use ZCML directives which use
-``zope.component.getGlobalSiteManager`` within a :mod:`pyramid`
+``zope.component.getGlobalSiteManager`` within a :app:`Pyramid`
 application without passing the ZCA global registry to the
 :term:`Configurator` constructor at application startup, as per
 :ref:`using_the_zca_global_registry`.