- Remove IResponder abstraction in favor of more general IResponse

  abstraction.

- It is now possible to return an arbitrary object from a Pyramid view
  callable even if a renderer is not used, as long as a suitable adapter to
  ``pyramid.interfaces.IResponse`` is registered for the type of the returned
  object.  See the section in the Hooks chapter of the documentation entitled
  "Changing How Pyramid Treats View Responses".

- The Pyramid router now, by default, expects response objects returned from
  view callables to implement the ``pyramid.interfaces.IResponse`` interface.
  Unlike the Pyramid 1.0 version of this interface, objects which implement
  IResponse now must define a ``__call__`` method that accepts ``environ``
  and ``start_response``, and which returns an ``app_iter`` iterable, among
  other things.  Previously, it was possible to return any object which had
  the three WebOb ``app_iter``, ``headerlist``, and ``status`` attributes as
  a response, so this is a backwards incompatibility.  It is possible to get
  backwards compatibility back by registering an adapter to IResponse from
  the type of object you're now returning from view callables.  See the
  section in the Hooks chapter of the documentation entitled "Changing How
  Pyramid Treats View Responses".

- The ``pyramid.interfaces.IResponse`` interface is now much more extensive.
  Previously it defined only ``app_iter``, ``status`` and ``headerlist``; now
  it is basically intended to directly mirror the ``webob.Response`` API,
  which has many methods and attributes.

- Documentation changes to support above.

1 files changed, 13 insertions, 23 deletions

diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 990828f80..e3d0a37e5 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -230,29 +230,19 @@ implements the :term:`Response` interface is to return a
    def view(request):
        return Response('OK')
 
-You don't need to use :class:`~pyramid.response.Response` to represent a
-response.  A view can actually return any object that has a ``__call__``
-method that implements the :term:`WSGI` application call interface.  For
-example, an instance of the following class could be successfully returned by
-a view callable as a response object:
-
-.. code-block:: python
-   :linenos:
-
-   class SimpleResponse(object):
-       def __call__(self, environ, start_response):
-           """ Call the ``start_response`` callback and return 
-               an iterable """
-           body = 'Hello World!'
-           headers = [('Content-Type', 'text/plain'),
-                      ('Content-Length', str(len(body)))]
-           start_response('200 OK', headers)
-           return [body]
-
-: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_exceptions` and ref:`http_redirect`).
+:app:`Pyramid` provides a range of different "exception" classes which
+inherit from :class:`pyramid.response.Response`.  For example, an instance of
+the class :class:`pyramid.httpexceptions.HTTPFound` is also a valid response
+object because it inherits from :class:`~pyramid.response.Response`.  For
+examples, see :ref:`http_exceptions` and ref:`http_redirect`.
+
+You can also return objects from view callables that aren't instances of (or
+instances of classes which are subclasses of)
+:class:`pyramid.response.Response` in various circumstances.  This can be
+helpful when writing tests and when attempting to share code between view
+callables.  See :ref:`renderers_chapter` for the common way to allow for
+this.  A much less common way to allow for view callables to return
+non-Response objects is documented in :ref:`using_iresponse`.
 
 .. index::
    single: view exceptions