Merge branch 'master' of https://github.com/Pylons/pyramid

11 files changed, 124 insertions, 34 deletions

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..2e737af04
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,13 @@
+language: python
+
+python:
+  - 2.6
+  - 2.7
+  - pypy
+  - 3.2
+
+matrix:
+  allow_failures:
+    - python: pypy
+
+script: python setup.py test
diff --git a/CONTRIBUTORS.txt b/CONTRIBUTORS.txt
index 98f73d5f9..c3995aaba 100644
--- a/CONTRIBUTORS.txt
+++ b/CONTRIBUTORS.txt
@@ -172,3 +172,7 @@ Contributors
 - Wayne Witzel III, 2012/03/27
 
 - Marin Rukavina, 2012/05/03
+
+- Marc Abramowitz, 2012/06/13
+
+- Jeff Cook, 2012/06/16
diff --git a/HACKING.txt b/HACKING.txt
index 593e89ac1..dd735bf22 100644
--- a/HACKING.txt
+++ b/HACKING.txt
@@ -113,23 +113,28 @@ Test Coverage
   ``nose`` and ``coverage`` into your virtualenv, and running ``setup.py
   nosetests --with-coverage``.
 
-Documentation Coverage
-----------------------
+Documentation Coverage and Building HTML Documentation
+------------------------------------------------------
 
-- If you fix a bug, and the bug requires an API or behavior
-  modification, all documentation in this package which references
-  that API or behavior must change to reflect the bug fix, ideally in
-  the same commit that fixes the bug or adds the feature.
+If you fix a bug, and the bug requires an API or behavior modification, all
+documentation in this package which references that API or behavior must
+change to reflect the bug fix, ideally in the same commit that fixes the bug
+or adds the feature.
 
-- To build and review docs:
+To build and review docs (where ``$yourvenv`` refers to the virtualenv you're
+using to develop Pyramid):
 
-  1. Install ``tests_require`` dependencies from Pyramid's setup.py into your
-     virtualenv.
+1. Run ``$yourvenv/bin/python setup.py dev docs``.  This will cause Sphinx
+   and all development requirements to be installed in your virtualenv.
 
-  2. From the ``docs`` directory of the Pyramid checkout run ``make html
-     SPHINXBUILD=/path/to/your/virtualenv/bin/sphinx-build``.
+2. cd to the ``docs`` directory within your Pyramid checkout and execute
+   ``make clean html SPHINXBUILD=$yourvenv/bin/sphinx-build``.  The
+   ``SPHINXBUILD=...`` hair is there in order to tell it to use the
+   virtualenv Python, which will have both Sphinx and Pyramid (for API
+   documentation generation) installed.
 
-  3.  Open the _build/html/index.html file to see the resulting rendering.
+3. Open the ``docs/_build/html/index.html`` file to see the resulting HTML
+   rendering.
 
 Change Log
 ----------
diff --git a/docs/narr/commandline.rst b/docs/narr/commandline.rst
index 4be436836..af53c1f78 100644
--- a/docs/narr/commandline.rst
+++ b/docs/narr/commandline.rst
@@ -654,8 +654,11 @@ use the following command:
 
 .. code-block:: python
 
-   import logging.config
-   logging.config.fileConfig('/path/to/my/development.ini')
+   import pyramid.paster
+   pyramid.paster.setup_logging('/path/to/my/development.ini')
+
+See :ref:`logging_chapter` for more information on logging within
+:app:`Pyramid`.
 
 .. index::
    single: console script
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index a2143b3c5..332805152 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -289,6 +289,36 @@ keys added to the renderer globals dictionary by all
 :class:`pyramid.events.BeforeRender` subscribers and renderer globals
 factories must be unique.
 
+The dictionary returned from the view is accessible through the
+:attr:`rendering_val` attribute of a :class:`~pyramid.events.BeforeRender`
+event.
+
+Suppose you return ``{'mykey': 'somevalue', 'mykey2': 'somevalue2'}`` from
+your view callable, like so:
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.view import view_config
+
+   @view_config(renderer='some_renderer')
+   def myview(request):
+       return {'mykey': 'somevalue', 'mykey2': 'somevalue2'}
+
+:attr:`rendering_val` can be used to access these values from the
+:class:`~pyramid.events.BeforeRender` object:
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.events import subscriber
+   from pyramid.events import BeforeRender
+
+   @subscriber(BeforeRender)
+   def read_return(event):
+       # {'mykey': 'somevalue'} is returned from the view
+       print(event.rendering_val['mykey'])
+
 See the API documentation for the :class:`~pyramid.events.BeforeRender` event
 interface at :class:`pyramid.interfaces.IBeforeRender`.
 
diff --git a/docs/narr/logging.rst b/docs/narr/logging.rst
index 044655c1f..f4c38abb6 100644
--- a/docs/narr/logging.rst
+++ b/docs/narr/logging.rst
@@ -14,7 +14,7 @@ how to send log messages to loggers that you've configured.
    which help configure logging.  All of the scaffolds which ship along with
    :app:`Pyramid` do this.  If you're not using a scaffold, or if you've used
    a third-party scaffold which does not create these files, the
-   configuration information in this chapter will not be applicable.
+   configuration information in this chapter may not be applicable.
 
 .. _logging_config:
 
@@ -36,10 +36,11 @@ application-related and logging-related sections in the configuration file
 can coexist peacefully, and the logging-related sections in the file are used
 from when you run ``pserve``.
 
-The ``pserve`` command calls the `logging.fileConfig function
+The ``pserve`` command calls the :func:`pyramid.paster.setup_logging`
+function, a thin wrapper around the `logging.fileConfig
 <http://docs.python.org/lib/logging-config-api.html>`_ using the specified
 ini file if it contains a ``[loggers]`` section (all of the
-scaffold-generated ``.ini`` files do). ``logging.fileConfig`` reads the
+scaffold-generated ``.ini`` files do). ``setup_logging`` reads the
 logging configuration from the ini file upon which ``pserve`` was
 invoked.
 
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index acbccbdfd..ecf3d026a 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -954,7 +954,7 @@ will be prepended with the first:
    from pyramid.config import Configurator
 
    def timing_include(config):
-       config.add_route('show_times', /times')
+       config.add_route('show_times', '/times')
 
    def users_include(config):
        config.add_route('show_users', '/show')
@@ -966,7 +966,7 @@ will be prepended with the first:
 
 In the above configuration, the ``show_users`` route will still have an
 effective route pattern of ``/users/show``.  The ``show_times`` route
-however, will have an effective pattern of ``/users/timing/show_times``.
+however, will have an effective pattern of ``/users/timing/times``.
 
 Route prefixes have no impact on the requirement that the set of route
 *names* in any given Pyramid configuration must be entirely unique.  If you
@@ -981,7 +981,7 @@ that may be added in the future.  For example:
    from pyramid.config import Configurator
 
    def timing_include(config):
-       config.add_route('timing.show_times', /times')
+       config.add_route('timing.show_times', '/times')
 
    def users_include(config):
        config.add_route('users.show_users', '/show')
diff --git a/pyramid/events.py b/pyramid/events.py
index e181ef33f..db274823c 100644
--- a/pyramid/events.py
+++ b/pyramid/events.py
@@ -200,10 +200,34 @@ class BeforeRender(dict):
     setting an overriding value (which can be done using ``.get`` or
     ``__contains__`` of the event object).
 
-    The event has an additional attribute named ``rendering_val``.  This is
-    the (non-system) value returned by a view or passed to ``render*`` as
-    ``value``.  This feature is new in Pyramid 1.2.
-    
+    The dictionary returned from the view is accessible through the
+    :attr:`rendering_val` attribute of a :class:`~pyramid.events.BeforeRender`
+    event.
+
+    Suppose you return ``{'mykey': 'somevalue', 'mykey2': 'somevalue2'}`` from
+    your view callable, like so::
+
+      from pyramid.view import view_config
+
+      @view_config(renderer='some_renderer')
+      def myview(request):
+          return {'mykey': 'somevalue', 'mykey2': 'somevalue2'}
+
+    :attr:`rendering_val` can be used to access these values from the
+    :class:`~pyramid.events.BeforeRender` object::
+
+      from pyramid.events import subscriber
+      from pyramid.events import BeforeRender
+
+      @subscriber(BeforeRender)
+      def read_return(event):
+          # {'mykey': 'somevalue'} is returned from the view
+          print(event.rendering_val['mykey'])
+
+    In other words, :attr:`rendering_val` is the (non-system) value returned by a
+    view or passed to ``render*`` as ``value``.  This feature is new in Pyramid
+    1.2.
+
     For a description of the values present in the renderer globals dictionary,
     see :ref:`renderer_system_values`.
 
diff --git a/pyramid/renderers.py b/pyramid/renderers.py
index c5d33dc16..e526f9997 100644
--- a/pyramid/renderers.py
+++ b/pyramid/renderers.py
@@ -65,10 +65,11 @@ def render(renderer_name, value, request=None, package=None):
     dictionary.  For other renderers, this will need to be whatever
     sort of value the renderer expects.
 
-    The 'system' values supplied to the renderer will include a basic
-    set of top-level system names, such as ``request``, ``context``,
-    and ``renderer_name``.  If :term:`renderer globals` have been
-    specified, these will also be used to agument the value.
+    The 'system' values supplied to the renderer will include a basic set of
+    top-level system names, such as ``request``, ``context``,
+    ``renderer_name``, and ``view``.  See :ref:`renderer_system_values` for
+    the full list.  If :term:`renderer globals` have been specified, these
+    will also be used to agument the value.
 
     Supply a ``request`` parameter in order to provide the renderer
     with the most correct 'system' values (``request`` and ``context``
@@ -108,10 +109,11 @@ def render_to_response(renderer_name, value, request=None, package=None):
     dictionary.  For other renderers, this will need to be whatever
     sort of value the renderer expects.
 
-    The 'system' values supplied to the renderer will include a basic
-    set of top-level system names, such as ``request``, ``context``,
-    and ``renderer_name``.  If :term:`renderer globals` have been
-    specified, these will also be used to agument the value.
+    The 'system' values supplied to the renderer will include a basic set of
+    top-level system names, such as ``request``, ``context``,
+    ``renderer_name``, and ``view``.  See :ref:`renderer_system_values` for
+    the full list.  If :term:`renderer globals` have been specified, these
+    will also be used to agument the value.
 
     Supply a ``request`` parameter in order to provide the renderer
     with the most correct 'system' values (``request`` and ``context``
diff --git a/pyramid/url.py b/pyramid/url.py
index dd83bb631..52e172d3f 100644
--- a/pyramid/url.py
+++ b/pyramid/url.py
@@ -711,7 +711,7 @@ class URLMethodsMixin(object):
            _app_url=request.script_name)``.
            :meth:`pyramid.request.Request.current_route_path` is, in fact,
            implemented in terms of
-           `:meth:`pyramid.request.Request.current_route_url` in just this
+           :meth:`pyramid.request.Request.current_route_url` in just this
            way. As a result, any ``_app_url`` passed within the ``**kw``
            values to ``current_route_path`` will be ignored.
         """
diff --git a/tox.ini b/tox.ini
index 97aa6c4d0..85bd41bda 100644
--- a/tox.ini
+++ b/tox.ini
@@ -1,6 +1,6 @@
 [tox]
 envlist = 
-    py26,py27,py32,pypy,cover
+    py26,py27,py32,py33,pypy,cover
 
 [testenv]
 commands = 
@@ -21,6 +21,14 @@ deps =
     virtualenv
     venusian
 
+[testenv:py33]
+commands = 
+    python setup.py test -q
+deps =
+    WebTest
+    virtualenv
+    venusian
+
 [testenv:cover]
 basepython =
     python2.6