Merge branch 'master' into feature.override-asset-with-absolute-path

14 files changed, 321 insertions, 390 deletions

diff --git a/docs/narr/MyProject/myproject/templates/mytemplate.pt b/docs/narr/MyProject/myproject/templates/mytemplate.pt
index d1af4f42c..e6b00a145 100644
--- a/docs/narr/MyProject/myproject/templates/mytemplate.pt
+++ b/docs/narr/MyProject/myproject/templates/mytemplate.pt
@@ -50,7 +50,7 @@
         </div>
         <div class="row">
           <div class="copyright">
-            Copyright © Pylons Project
+            Copyright &copy; Pylons Project
           </div>
         </div>
       </div>
diff --git a/docs/narr/MyProject/setup.cfg b/docs/narr/MyProject/setup.cfg
deleted file mode 100644
index 332e80a60..000000000
--- a/docs/narr/MyProject/setup.cfg
+++ /dev/null
@@ -1,27 +0,0 @@
-[nosetests]
-match = ^test
-nocapture = 1
-cover-package = myproject
-with-coverage = 1
-cover-erase = 1
-
-[compile_catalog]
-directory = myproject/locale
-domain = MyProject
-statistics = true
-
-[extract_messages]
-add_comments = TRANSLATORS:
-output_file = myproject/locale/MyProject.pot
-width = 80
-
-[init_catalog]
-domain = MyProject
-input_file = myproject/locale/MyProject.pot
-output_dir = myproject/locale
-
-[update_catalog]
-domain = MyProject
-input_file = myproject/locale/MyProject.pot
-output_dir = myproject/locale
-previous = true
diff --git a/docs/narr/assets.rst b/docs/narr/assets.rst
index fec55ce7c..74708ff3e 100644
--- a/docs/narr/assets.rst
+++ b/docs/narr/assets.rst
@@ -287,6 +287,181 @@ suggestion for a pattern; any setting name other than ``media_location``
 could be used.
 
 .. index::
+   single: Cache Busting
+
+.. _cache_busting:
+
+Cache Busting
+-------------
+
+.. versionadded:: 1.6
+
+In order to maximize performance of a web application, you generally want to 
+limit the number of times a particular client requests the same static asset.
+Ideally a client would cache a particular static asset "forever", requiring 
+it to be sent to the client a single time.  The HTTP protocol allows you to 
+send headers with an HTTP response that can instruct a client to cache a 
+particular asset for an amount of time.  As long as the client has a copy of 
+the asset in its cache and that cache hasn't expired, the client will use the
+cached copy rather than request a new copy from the server.  The drawback to 
+sending cache headers to the client for a static asset is that at some point
+the static asset may change, and then you'll want the client to load a new copy
+of the asset.  Under normal circumstances you'd just need to wait for the 
+client's cached copy to expire before they get the new version of the static 
+resource.
+
+A commonly used workaround to this problem is a technique known as "cache 
+busting".  Cache busting schemes generally involve generating a URL for a 
+static asset that changes when the static asset changes.  This way headers can
+be sent along with the static asset instructing the client to cache the asset
+for a very long time.  When a static asset is changed, the URL used to refer to
+it in a web page also changes, so the client sees it as a new resource and 
+requests a copy, regardless of any caching policy set for the resource's old 
+URL.
+
+:app:`Pyramid` can be configured to produce cache busting URLs for static 
+assets by passing the optional argument, ``cachebust`` to 
+:meth:`~pyramid.config.Configurator.add_static_view`:
+
+.. code-block:: python
+   :linenos:
+
+   # config is an instance of pyramid.config.Configurator
+   config.add_static_view(name='static', path='mypackage:folder/static',
+                          cachebust=True)
+
+Setting the ``cachebust`` argument instructs :app:`Pyramid` to use a cache 
+busting scheme which adds the md5 checksum for a static asset as a path segment
+in the asset's URL:
+
+.. code-block:: python
+   :linenos:
+
+   js_url = request.static_url('mypackage:folder/static/js/myapp.js')
+   # Returns: 'http://www.example.com/static/c9658b3c0a314a1ca21e5988e662a09e/js/myapp.js`
+
+When the asset changes, so will its md5 checksum, and therefore so will its
+URL.  Supplying the ``cachebust`` argument also causes the static view to set
+headers instructing clients to cache the asset for ten years, unless the
+``max_cache_age`` argument is also passed, in which case that value is used.
+
+.. note:: 
+
+   md5 checksums are cached in RAM so if you change a static resource without
+   restarting your application, you may still generate URLs with a stale md5
+   checksum. 
+
+Disabling the Cache Buster
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It can be useful in some situations (e.g. development) to globally disable all
+configured cache busters without changing calls to
+:meth:`~pyramid.config.Configurator.add_static_view`.  To do this set the 
+``PYRAMID_PREVENT_CACHEBUST`` environment variable or the 
+``pyramid.prevent_cachebust`` configuration value to a true value.
+
+Customizing the Cache Buster
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Revisiting from the previous section:
+
+.. code-block:: python
+   :linenos:
+
+   # config is an instance of pyramid.config.Configurator
+   config.add_static_view(name='static', path='mypackage:folder/static',
+                          cachebust=True)
+
+Setting ``cachebust`` to ``True`` instructs :app:`Pyramid` to use a default
+cache busting implementation that should work for many situations.  The 
+``cachebust`` may be set to any object that implements the interface,
+:class:`~pyramid.interfaces.ICacheBuster`.  The above configuration is exactly
+equivalent to:
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.static import PathSegmentMd5CacheBuster
+
+   # config is an instance of pyramid.config.Configurator
+   config.add_static_view(name='static', path='mypackage:folder/static',
+                          cachebust=PathSegmentMd5CacheBuster())
+
+:app:`Pyramid` includes a handful of ready to use cache buster implementations:
+:class:`~pyramid.static.PathSegmentMd5CacheBuster`, which inserts an md5
+checksum token in the path portion of the asset's URL,
+:class:`~pyramid.static.QueryStringMd5CacheBuster`, which adds an md5 checksum
+token to the query string of the asset's URL, and
+:class:`~pyramid.static.QueryStringConstantCacheBuster`, which adds an
+arbitrary token you provide to the query string of the asset's URL.  
+
+In order to implement your own cache buster, you can write your own class from
+scratch which implements the :class:`~pyramid.interfaces.ICacheBuster`
+interface.  Alternatively you may choose to subclass one of the existing
+implementations.  One of the most likely scenarios is you'd want to change the
+way the asset token is generated.  To do this just subclass an existing
+implementation and replace the :meth:`~pyramid.interfaces.ICacheBuster.token`
+method.  Here is an example which just uses Git to get the hash of the 
+currently checked out code:
+
+.. code-block:: python
+   :linenos:
+
+   import os
+   import subprocess
+   from pyramid.static import PathSegmentMd5CacheBuster
+
+   class GitCacheBuster(PathSegmentMd5CacheBuster):
+       """
+       Assuming your code is installed as a Git checkout, as opposed to as an
+       egg from an egg repository like PYPI, you can use this cachebuster to
+       get the current commit's SHA1 to use as the cache bust token.
+       """
+       def __init__(self):
+           here = os.path.dirname(os.path.abspath(__file__))
+           self.sha1 = subprocess.check_output(
+               ['git', 'rev-parse', 'HEAD'],
+               cwd=here).strip()
+
+       def token(self, pathspec):
+           return self.sha1
+   
+Choosing a Cache Buster
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The default cache buster implementation, 
+:class:`~pyramid.static.PathSegmentMd5CacheBuster`, works very well assuming 
+that you're using :app:`Pyramid` to serve your static assets.  The md5 checksum
+is fine grained enough that browsers should only request new versions of 
+specific assets that have changed.  Many caching HTTP proxies will fail to 
+cache a resource if the URL contains a query string.  In general, therefore, 
+you should prefer a cache busting strategy which modifies the path segment to
+a strategy which adds a query string.  
+
+It is possible, however, that your static assets are being served by another
+web server or externally on a CDN.  In these cases modifying the path segment
+for a static asset URL would cause the external service to fail to find the
+asset, causing your customer to get a 404.  In these cases you would need to 
+fall back to a cache buster which adds a query string.  It is even possible 
+that there isn't a copy of your static assets available to the :app:`Pyramid`
+application, so a cache busting implementation that generates md5 checksums
+would fail since it can't access the assets.  In such a case, 
+:class:`~pyramid.static.QueryStringConstantCacheBuster` is a reasonable 
+fallback.  The following code would set up a cachebuster that just uses the 
+time at start up as a cachebust token:
+
+.. code-block:: python
+   :linenos:
+
+   import time
+   from pyramid.static import QueryStringConstantCacheBuster
+
+   config.add_static_view(
+       name='http://mycdn.example.com/', 
+       path='mypackage:static',
+       cachebust=QueryStringConstantCacheBuster(str(time.time())))
+
+.. index::
    single: static assets view
 
 .. _advanced_static:
diff --git a/docs/narr/commandline.rst b/docs/narr/commandline.rst
index 3cabbd8f4..4f16617c4 100644
--- a/docs/narr/commandline.rst
+++ b/docs/narr/commandline.rst
@@ -146,7 +146,7 @@ name ``main`` as a section name:
 
 .. code-block:: text
 
-    $ $VENV/bin starter/development.ini#main
+    $ $VENV/bin/pshell starter/development.ini#main
     Python 2.6.5 (r265:79063, Apr 29 2010, 00:31:32) 
     [GCC 4.4.3] on linux2
     Type "help" for more information.
diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst
index f7a69d613..52615533d 100644
--- a/docs/narr/configuration.rst
+++ b/docs/narr/configuration.rst
@@ -114,7 +114,6 @@ in a package and its subpackages.  For example:
        return Response('Hello')
 
    if __name__ == '__main__':
-       from pyramid.config import Configurator
        config = Configurator()
        config.scan()
        app = config.make_wsgi_app()
diff --git a/docs/narr/environment.rst b/docs/narr/environment.rst
index 412635f08..0b06fb80b 100644
--- a/docs/narr/environment.rst
+++ b/docs/narr/environment.rst
@@ -13,7 +13,6 @@
    single: reload settings
    single: default_locale_name
    single: environment variables
-   single: Mako environment settings
    single: ini file settings
    single: PasteDeploy settings
 
@@ -158,6 +157,28 @@ feature when this is true.
 |                                 |                                  |
 +---------------------------------+----------------------------------+
 
+Preventing Cache Busting
+------------------------
+
+Prevent the ``cachebust`` static view configuration argument from having any
+effect globally in this process when this value is true.  No cache buster will
+be configured or used when this is true.  
+
+.. versionadded:: 1.6
+
+.. seealso::
+
+    See also :ref:`cache_busting`.
+
++---------------------------------+----------------------------------+
+| Environment Variable Name       | Config File Setting Name         |
++=================================+==================================+
+| ``PYRAMID_PREVENT_CACHEBUST``   |  ``pyramid.prevent_cachebust``   |
+|                                 |  or ``prevent_cachebust``        |
+|                                 |                                  |
+|                                 |                                  |
++---------------------------------+----------------------------------+
+
 Debugging All
 -------------
 
@@ -396,153 +417,6 @@ Is equivalent to using the following statements in your configuration code:
 
 It is fine to use both or either form.
 
-.. _mako_template_renderer_settings:
-
-Mako Template Render Settings
------------------------------
-
-Mako derives additional settings to configure its template renderer that
-should be set when using it. Many of these settings are optional and only need
-to be set if they should be different from the default. The Mako Template
-Renderer uses a subclass of Mako's `template lookup
-<http://www.makotemplates.org/docs/usage.html#usage_lookup>`_ and accepts
-several arguments to configure it.
-
-Mako Directories
-~~~~~~~~~~~~~~~~
-
-The value(s) supplied here are passed in as the template directories. They
-should be in :term:`asset specification` format, for example:
-``my.package:templates``.
-
-+-----------------------------+
-| Config File Setting Name    |
-+=============================+
-|  ``mako.directories``       |
-|                             |
-|                             |
-|                             |
-+-----------------------------+
-
-Mako Module Directory
-~~~~~~~~~~~~~~~~~~~~~
-
-The value supplied here tells Mako where to store compiled Mako templates. If
-omitted, compiled templates will be stored in memory. This value should be an
-absolute path, for example: ``%(here)s/data/templates`` would use a directory
-called ``data/templates`` in the same parent directory as the INI file.
-
-+-----------------------------+
-| Config File Setting Name    |
-+=============================+
-|  ``mako.module_directory``  |
-|                             |
-|                             |
-|                             |
-+-----------------------------+
-
-Mako Input Encoding
-~~~~~~~~~~~~~~~~~~~
-
-The encoding that Mako templates are assumed to have. By default this is set
-to ``utf-8``. If you wish to use a different template encoding, this value
-should be changed accordingly.
-
-+-----------------------------+
-| Config File Setting Name    |
-+=============================+
-|  ``mako.input_encoding``    |
-|                             |
-|                             |
-|                             |
-+-----------------------------+
-
-Mako Error Handler
-~~~~~~~~~~~~~~~~~~
-
-A callable (or a :term:`dotted Python name` which names a callable) which is
-called whenever Mako compile or runtime exceptions occur. The callable is
-passed the current context as well as the exception. If the callable returns
-True, the exception is considered to be handled, else it is re-raised after
-the function completes. Is used to provide custom error-rendering functions.
-
-+-----------------------------+
-| Config File Setting Name    |
-+=============================+
-|  ``mako.error_handler``     |
-|                             |
-|                             |
-|                             |
-+-----------------------------+
-
-Mako Default Filters
-~~~~~~~~~~~~~~~~~~~~
-
-List of string filter names that will be applied to all Mako expressions.
-
-+-----------------------------+
-| Config File Setting Name    |
-+=============================+
-|  ``mako.default_filters``   |
-|                             |
-|                             |
-|                             |
-+-----------------------------+
-
-Mako Import
-~~~~~~~~~~~
-
-String list of Python statements, typically individual "import" lines, which
-will be placed into the module level preamble of all generated Python modules.
-
-
-+-----------------------------+
-| Config File Setting Name    |
-+=============================+
-|  ``mako.imports``           |
-|                             |
-|                             |
-|                             |
-+-----------------------------+
-
-
-Mako Strict Undefined
-~~~~~~~~~~~~~~~~~~~~~
-
-``true`` or ``false``, representing the "strict undefined" behavior of Mako
-(see `Mako Context Variables
-<http://www.makotemplates.org/docs/runtime.html#context-variables>`_).  By
-default, this is ``false``.
-
-+-----------------------------+
-| Config File Setting Name    |
-+=============================+
-|  ``mako.strict_undefined``  |
-|                             |
-|                             |
-|                             |
-+-----------------------------+
-
-Mako Preprocessor
-~~~~~~~~~~~~~~~~~
-
-.. versionadded:: 1.1
-
-A callable (or a :term:`dotted Python name` which names a callable) which is
-called to preprocess the source before the template is called.  The callable
-will be passed the full template source before it is parsed. The return
-result of the callable will be used as the template source code.
-
-
-+-----------------------------+
-| Config File Setting Name    |
-+=============================+
-|  ``mako.preprocessor``      |
-|                             |
-|                             |
-|                             |
-+-----------------------------+
-
 Examples
 --------
 
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index f2542f1d7..4da36e730 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -985,7 +985,7 @@ Creating a Tween
 
 To create a tween, you must write a "tween factory".  A tween factory
 must be a globally importable callable which accepts two arguments:
-``handler`` and ``registry``.  ``handler`` will be the either the main
+``handler`` and ``registry``.  ``handler`` will be either the main
 Pyramid request handling function or another tween.  ``registry`` will be the
 Pyramid :term:`application registry` represented by this Configurator.  A
 tween factory must return the tween (a callable object) when it is called.
@@ -1023,7 +1023,7 @@ method:
     :linenos:
 
     class simple_tween_factory(object):
-        def __init__(handler, registry):
+        def __init__(self, handler, registry):
             self.handler = handler
             self.registry = registry
 
@@ -1040,6 +1040,10 @@ method:
 
             return response
 
+You should avoid mutating any state on the tween instance. The tween is
+invoked once per request and any shared mutable state needs to be carefully
+handled to avoid any race conditions.
+
 The closure style performs slightly better and enables you to conditionally
 omit the tween from the request processing pipeline (see the following timing
 tween example), whereas the class style makes it easier to have shared mutable
diff --git a/docs/narr/i18n.rst b/docs/narr/i18n.rst
index 5f50ca212..95f663584 100644
--- a/docs/narr/i18n.rst
+++ b/docs/narr/i18n.rst
@@ -245,88 +245,70 @@ GNU gettext uses three types of files in the translation framework,
 
   A ``.po`` file is turned into a machine-readable binary file, which
   is the ``.mo`` file. Compiling the translations to machine code
-  makes the localized program run faster.
+  makes the localized program start faster.
 
 The tools for working with :term:`gettext` translation files related to a
-:app:`Pyramid` application is :term:`Babel` and :term:`Lingua`.  Lingua is a
-Babel extension that provides support for scraping i18n references out of
-Python and Chameleon files.
+:app:`Pyramid` application are :term:`Lingua` and :term:`Gettext`. Lingua
+can scrape i18n references out of Python and Chameleon files and create
+the ``.pot`` file. Gettext includes ``msgmerge`` tool to update a ``.po`` file
+from an updated ``.pot`` file and ``msgfmt`` to compile ``.po`` files to
+``.mo`` files.
 
 .. index::
-   single: Babel
+   single: Gettext
    single: Lingua
 
 .. _installing_babel:
 
-Installing Babel and Lingua
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Installing Lingua and Gettext
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In order for the commands related to working with ``gettext`` translation
-files to work properly, you will need to have :term:`Babel` and
-:term:`Lingua` installed into the same environment in which :app:`Pyramid` is
+files to work properly, you will need to have :term:`Lingua` and
+:term:`Gettext` installed into the same environment in which :app:`Pyramid` is
 installed.
 
 Installation on UNIX
 ++++++++++++++++++++
 
-If the :term:`virtualenv` into which you've installed your :app:`Pyramid`
-application lives in ``/my/virtualenv``, you can install Babel and Lingua
-like so:
+Gettext is often already installed on UNIX systems. You can check if it is
+installed by testing if the ``msgfmt`` command is available. If it is not
+available you can install it through the packaging system from your OS;
+the package name is almost always ``gettext``. For example on a Debian or
+Ubuntu system run this command:
 
 .. code-block:: text
 
-   $ cd /my/virtualenv
-   $ $VENV/bin/easy_install Babel lingua
+   $ sudo apt-get install gettext
 
-Installation on Windows
-+++++++++++++++++++++++
-
-If the :term:`virtualenv` into which you've installed your :app:`Pyramid`
-application lives in ``C:\my\virtualenv``, you can install Babel and Lingua
+Installing Lingua is done with the Python packaging tools. If the
+:term:`virtualenv` into which you've installed your :app:`Pyramid` application
+lives in ``/my/virtualenv``, you can install Lingua
 like so:
 
 .. code-block:: text
 
-   C> %VENV%\Scripts\easy_install Babel lingua
+   $ cd /my/virtualenv
+   $ $VENV/bin/easy_install lingua
 
-.. index::
-   single: Babel; message extractors
-   single: Lingua
+Installation on Windows
++++++++++++++++++++++++
 
-Changing the ``setup.py``
-+++++++++++++++++++++++++
+There are several ways to install Gettext on Windows: it is included in the
+`Cygwin <http://www.cygwin.com/>`_ collection, or you can use the `installer
+from the GnuWin32 <http://gnuwin32.sourceforge.net/packages/gettext.htm>`_
+or compile it yourself. Make sure the installation path is added to your
+``$PATH``.
 
-You need to add a few boilerplate lines to your application's ``setup.py``
-file in order to properly generate :term:`gettext` files from your
-application.
 
-.. note:: See :ref:`project_narr` to learn about the
-  composition of an application's ``setup.py`` file.
+Installing Lingua is done with the Python packaging tools. If the
+:term:`virtualenv` into which you've installed your :app:`Pyramid` application
+lives in ``C:\my\virtualenv``, you can install Lingua like so:
 
-In particular, add the ``Babel`` and ``lingua`` distributions to the
-``install_requires`` list and insert a set of references to :term:`Babel`
-*message extractors* within the call to :func:`setuptools.setup` inside your
-application's ``setup.py`` file:
+.. code-block:: text
 
-.. code-block:: python
-    :linenos:
+   C> %VENV%\Scripts\easy_install lingua
 
-    setup(name="mypackage",
-          # ...
-          install_requires = [
-                # ...
-                'Babel',
-                'lingua',
-                ],
-          message_extractors = { '.': [
-                ('**.py',   'lingua_python', None ),
-                ('**.pt',   'lingua_xml', None ),
-                ]},
-          )
-
-The ``message_extractors`` stanza placed into the ``setup.py`` file causes
-the :term:`Babel` message catalog extraction machinery to also consider
-``*.pt`` files when doing message id extraction.
 
 .. index::
    pair: extracting; messages
@@ -336,90 +318,20 @@ the :term:`Babel` message catalog extraction machinery to also consider
 Extracting Messages from Code and Templates
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Once Babel and Lingua are 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 :app:`Pyramid` application.  You run a ``setup.py`` command to
-extract the messages:
+Once Lingua is installed you may extract a message catalog template from the
+code and :term:`Chameleon` templates which reside in your :app:`Pyramid`
+application.  You run a ``pot-create`` command to extract the messages:
 
 .. code-block:: text
 
    $ cd /place/where/myapplication/setup.py/lives
    $ mkdir -p myapplication/locale
-   $ $VENV/bin/python setup.py extract_messages
+   $ $VENV/bin/pot-create -o myapplication/locale/myapplication.pot src
 
 The message catalog ``.pot`` template will end up in:
 
 ``myapplication/locale/myapplication.pot``.
 
-.. index::
-   single: translation domains
-
-Translation Domains
-+++++++++++++++++++
-
-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
-: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 ``pcreate`` -generated :app:`Pyramid` application has stanzas in it
-that look something like the following:
-
-.. code-block:: ini
-    :linenos:
-
-    [compile_catalog]
-    directory = myproject/locale
-    domain = MyProject
-    statistics = true
-
-    [extract_messages]
-    add_comments = TRANSLATORS:
-    output_file = myproject/locale/MyProject.pot
-    width = 80
-
-    [init_catalog]
-    domain = MyProject
-    input_file = myproject/locale/MyProject.pot
-    output_dir = myproject/locale
-
-    [update_catalog]
-    domain = MyProject
-    input_file = myproject/locale/MyProject.pot
-    output_dir = myproject/locale
-    previous = true
-
-In the above example, the project name is ``MyProject``.  To indicate
-that you'd like the domain of your translations to be ``mydomain``
-instead, change the ``setup.cfg`` file stanzas to look like so:
-
-.. code-block:: ini
-    :linenos:
-
-    [compile_catalog]
-    directory = myproject/locale
-    domain = mydomain
-    statistics = true
-
-    [extract_messages]
-    add_comments = TRANSLATORS:
-    output_file = myproject/locale/mydomain.pot
-    width = 80
-
-    [init_catalog]
-    domain = mydomain
-    input_file = myproject/locale/mydomain.pot
-    output_dir = myproject/locale
-
-    [update_catalog]
-    domain = mydomain
-    input_file = myproject/locale/mydomain.pot
-    output_dir = myproject/locale
-    previous = true
 
 .. index::
    pair: initializing; message catalog
@@ -432,15 +344,17 @@ Once you've extracted messages into a ``.pot`` file (see
 in the ``.pot`` file, you need to generate at least one ``.po`` file.
 A ``.po`` file represents translations of a particular set of messages
 to a particular locale.  Initialize a ``.po`` file for a specific
-locale from a pre-generated ``.pot`` template by using the ``setup.py
-init_catalog`` command:
+locale from a pre-generated ``.pot`` template by using the ``msginit``
+command from Gettext:
 
 .. code-block:: text
 
    $ cd /place/where/myapplication/setup.py/lives
-   $ $VENV/bin/python setup.py init_catalog -l es
+   $ cd myapplication/locale
+   $ mkdir -p es/LC_MESSAGES
+   $ msginit -l es -o es/LC_MESSAGES/myapplication.po
 
-By default, the message catalog ``.po`` file will end up in:
+This will create a new the message catalog ``.po`` file will in:
 
 ``myapplication/locale/es/LC_MESSAGES/myapplication.po``.
 
@@ -465,12 +379,13 @@ files based on changes to the ``.pot`` file, so that the new and
 changed messages can also be translated or re-translated.
 
 First, regenerate the ``.pot`` file as per :ref:`extracting_messages`.
-Then use the ``setup.py update_catalog`` command.
+Then use the ``msgmerge`` command from Gettext.
 
 .. code-block:: text
 
    $ cd /place/where/myapplication/setup.py/lives
-   $ $VENV/bin/python setup.py update_catalog
+   $ cd myapplication/locale
+   $ msgmerge --update es/LC_MESSAGES/myapplication.po myapplication.pot
 
 .. index::
    pair: compiling; message catalog
@@ -481,16 +396,17 @@ Compiling a Message Catalog File
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Finally, to prepare an application for performing actual runtime
-translations, compile ``.po`` files to ``.mo`` files:
+translations, compile ``.po`` files to ``.mo`` files use the ``msgfmt``
+command from Gettext:
 
 .. code-block:: text
 
    $ cd /place/where/myapplication/setup.py/lives
-   $ $VENV/bin/python setup.py compile_catalog
+   $ msgfmt -o myapplication/locale/es/LC_MESSAGES/myapplication.mo myapplication/locale/es/LC_MESSAGES/myapplication.po
 
 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
+the ``.mo`` file ends up in is configured into your application (see :ref:`adding_a_translation_directory`), these
 translations will be available to :app:`Pyramid`.
 
 .. index::
diff --git a/docs/narr/install.rst b/docs/narr/install.rst
index e419a8b20..a825b61b9 100644
--- a/docs/narr/install.rst
+++ b/docs/narr/install.rst
@@ -15,8 +15,8 @@ You will need `Python <http://python.org>`_ version 2.6 or better to run
 .. sidebar:: Python Versions
 
     As of this writing, :app:`Pyramid` has been tested under Python 2.6, Python
-    2.7, Python 3.2, and Python 3.3.  :app:`Pyramid` does not run under any
-    version of Python before 2.6.
+    2.7, Python 3.2, Python 3.3, Python 3.4 and PyPy 2.2. :app:`Pyramid` does
+    not run under any version of Python before 2.6.
 
 :app:`Pyramid` is known to run on all popular UNIX-like systems such as Linux,
 Mac OS X, and FreeBSD as well as on Windows platforms.  It is also known to run
@@ -32,20 +32,22 @@ dependency will fall back to using pure Python instead.
 For Mac OS X Users
 ~~~~~~~~~~~~~~~~~~
 
-From `Python.org <http://python.org/download/mac/>`_:
+Python comes pre-installed on Mac OS X, but due to Apple's release cycle,
+it is often out of date. Unless you have a need for a specific earlier version,
+it is recommended to install the latest 2.x or 3.x version of Python.
 
-    Python comes pre-installed on Mac OS X, but due to Apple's release cycle,
-    it's often one or even two years old. The overwhelming recommendation of
-    the "MacPython" community is to upgrade your Python by downloading and
-    installing a newer version from `the Python standard release page
-    <http://python.org/download/releases/>`_.
+You can install the latest verion of Python for Mac OS X from the binaries on
+`python.org <https://www.python.org/download/mac/>`_.
 
-It is recommended to download one of the *installer* versions, unless you
-prefer to install your Python through a packgage manager (e.g., macports or
-homebrew) or to build your Python from source.
+Alternatively, you can use the `homebrew <http://brew.sh/>`_ package manager.
 
-Unless you have a need for a specific earlier version, it is recommended to
-install the latest 2.x or 3.x version of Python.
+.. code-block:: text
+
+   # for python 2.7
+   $ brew install python
+
+   # for python 3.4
+   $ brew install python3
 
 If you use an installer for your Python, then you can skip to the section
 :ref:`installing_unix`.
diff --git a/docs/narr/logging.rst b/docs/narr/logging.rst
index 75428d513..71029bb33 100644
--- a/docs/narr/logging.rst
+++ b/docs/narr/logging.rst
@@ -377,7 +377,7 @@ FileHandler to the list of handlers (named ``accesslog``), and ensure that the
 
     [logger_wsgi] 
     level = INFO 
-    handlers = handler_accesslog
+    handlers = accesslog
     qualname = wsgi 
     propagate = 0 
 
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 62b91de0e..0ada1a379 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -476,24 +476,23 @@ structure:
 .. code-block:: text
 
   MyProject/
-  ├── CHANGES.txt
-  ├── MANIFEST.in
-  ├── README.txt
-  ├── development.ini
-  ├── myproject
-  │   ├── __init__.py
-  │   ├── static
-  │   │   ├── pyramid-16x16.png
-  │   │   ├── pyramid.png
-  │   │   ├── theme.css
-  │   │   └── theme.min.css
-  │   ├── templates
-  │   │   └── mytemplate.pt
-  │   ├── tests.py
-  │   └── views.py
-  ├── production.ini
-  ├── setup.cfg
-  └── setup.py
+  |-- CHANGES.txt
+  |-- development.ini
+  |-- MANIFEST.in
+  |-- myproject
+  |   |-- __init__.py
+  |   |-- static
+  |   |   |-- pyramid-16x16.png
+  |   |   |-- pyramid.png
+  |   |   |-- theme.css
+  |   |   `-- theme.min.css
+  |   |-- templates
+  |   |   `-- mytemplate.pt
+  |   |-- tests.py
+  |   `-- views.py
+  |-- production.ini
+  |-- README.txt
+  `-- setup.py
 
 The ``MyProject`` :term:`Project`
 ---------------------------------
@@ -515,9 +514,6 @@ describe, run, and test your application.
 #. ``production.ini`` is a :term:`PasteDeploy` configuration file that can
    be used to execute your application in a production configuration.
 
-#. ``setup.cfg`` is a :term:`setuptools` configuration file used by
-   ``setup.py``.
-
 #. ``MANIFEST.in`` is a :term:`distutils` "manifest" file, naming which files
    should be included in a source distribution of the package when ``python
    setup.py sdist`` is run.
@@ -746,24 +742,6 @@ named ``MyProject-0.1.tar.gz``.  You can send this tarball to other people
 who want to install and use your application.
 
 .. index::
-   single: setup.cfg
-
-``setup.cfg``
-~~~~~~~~~~~~~
-
-The ``setup.cfg`` file is a :term:`setuptools` configuration file.  It
-contains various settings related to testing and internationalization:
-
-Our generated ``setup.cfg`` looks like this:
-
-.. literalinclude:: MyProject/setup.cfg
-   :language: guess
-   :linenos:
-
-The values in the default setup file allow various commonly-used
-internationalization commands and testing commands to work more smoothly.
-
-.. index::
    single: package
 
 The ``myproject`` :term:`Package`
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 038dd2594..4c1364493 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -316,8 +316,7 @@ template renderer:
    we're using a Chameleon renderer, it means "relative to the directory in
    which the file which defines the view configuration lives".  In this case,
    this is the directory containing the file that defines the ``my_view``
-   function.  View-configuration-relative asset specifications work only
-   in Chameleon, not in Mako templates.
+   function.
 
 Similar renderer configuration can be done imperatively.  See
 :ref:`views_which_use_a_renderer`.
@@ -450,21 +449,24 @@ Available Add-On Template System Bindings
 The Pylons Project maintains several packages providing bindings to different
 templating languages including the following:
 
-+------------------------------+------------------------------+
-| Template Language            | Pyramid Bindings             |
-+==============================+==============================+
-| Chameleon_                   | pyramid_chameleon_           |
-+------------------------------+------------------------------+
-| Jinja2_                      | pyramid_jinja2_              |
-+------------------------------+------------------------------+
-| Mako_                        | pyramid_mako_                |
-+------------------------------+------------------------------+
++---------------------------+----------------------------+--------------------+
+| Template Language         | Pyramid Bindings           | Default Extensions |
++===========================+============================+====================+
+| Chameleon_                | pyramid_chameleon_         | .pt, .txt          |
++---------------------------+----------------------------+--------------------+
+| Jinja2_                   | pyramid_jinja2_            | .jinja2            |
++---------------------------+----------------------------+--------------------+
+| Mako_                     | pyramid_mako_              | .mak, .mako        |
++---------------------------+----------------------------+--------------------+
 
 .. _Chameleon: http://chameleon.readthedocs.org/en/latest/
-.. _pyramid_chameleon: https://pypi.python.org/pypi/pyramid_chameleon
+.. _pyramid_chameleon:
+   http://docs.pylonsproject.org/projects/pyramid-chameleon/en/latest/
 
 .. _Jinja2: http://jinja.pocoo.org/docs/
-.. _pyramid_jinja2: https://pypi.python.org/pypi/pyramid_jinja2
+.. _pyramid_jinja2:
+   http://docs.pylonsproject.org/projects/pyramid-jinja2/en/latest/
 
 .. _Mako: http://www.makotemplates.org/
-.. _pyramid_mako: https://pypi.python.org/pypi/pyramid_mako
+.. _pyramid_mako:
+   http://docs.pylonsproject.org/projects/pyramid-mako/en/latest/
diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst
index adc53bd11..a0feef8d7 100644
--- a/docs/narr/viewconfig.rst
+++ b/docs/narr/viewconfig.rst
@@ -295,11 +295,14 @@ configured view.
   *This is an advanced feature, not often used by "civilians"*.
 
 ``request_method``
-  This value can be a string (typically ``"GET"``, ``"POST"``, ``"PUT"``,
-  ``"DELETE"``, or ``"HEAD"``) representing an HTTP ``REQUEST_METHOD``.  A view
-  declaration with this argument ensures that the view will only be called
-  when the request's ``method`` attribute (aka the ``REQUEST_METHOD`` of the
-  WSGI environment) string matches the supplied value.
+  This value can be either a string (such as ``"GET"``, ``"POST"``,
+  ``"PUT"``, ``"DELETE"``, ``"HEAD"`` or ``"OPTIONS"``) representing an
+  HTTP ``REQUEST_METHOD``, or a tuple containing one or more of these
+  strings.  A view declaration with this argument ensures that the
+  view will only be called when the ``method`` attribute of the
+  request (aka the ``REQUEST_METHOD`` of the WSGI environment) matches
+  a supplied value.  Note that use of ``"GET"`` also implies that the
+  view will respond to ``"HEAD"`` as of Pyramid 1.4.
 
   If ``request_method`` is not supplied, the view will be invoked regardless
   of the ``REQUEST_METHOD`` of the :term:`WSGI` environment.
diff --git a/docs/narr/webob.rst b/docs/narr/webob.rst
index f0a4b5a0b..6a331e4bf 100644
--- a/docs/narr/webob.rst
+++ b/docs/narr/webob.rst
@@ -408,6 +408,8 @@ Here are some highlights:
     The content type *not* including the ``charset`` parameter.
     Typical use: ``response.content_type = 'text/html'``.
 
+    Default value: ``response.content_type = 'text/html'``.
+
 ``response.charset``:
     The ``charset`` parameter of the content-type, it also informs
     encoding in ``response.unicode_body``.
@@ -466,9 +468,12 @@ argument to the class; e.g.:
   from pyramid.response import Response
   response = Response(body='hello world!', content_type='text/plain')
 
-The status defaults to ``'200 OK'``.  The content_type does not default to
-anything, though if you subclass :class:`pyramid.response.Response` and set
-``default_content_type`` you can override this behavior.
+The status defaults to ``'200 OK'``.
+
+The value of content_type defaults to
+``webob.response.Response.default_content_type``; which is `text/html`.
+You can subclass :class:`pyramid.response.Response` and set
+``default_content_type`` to override this behavior.
 
 .. index::
    single: exception responses