- 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, 18 insertions, 15 deletions

diff --git a/docs/api/request.rst b/docs/api/request.rst
index 8cb424658..27ce395ac 100644
--- a/docs/api/request.rst
+++ b/docs/api/request.rst
@@ -107,7 +107,9 @@
          return {'text':'Value that will be used by the renderer'}
 
      Mutations to this response object will be preserved in the response sent
-     to the client after rendering.
+     to the client after rendering.  For more information about using
+     ``request.response`` in conjunction with a renderer, see
+     :ref:`request_response_attr`.
 
      Non-renderer code can also make use of request.response instead of
      creating a response "by hand".  For example, in view code::
@@ -162,20 +164,21 @@
 
    .. attribute::  response_*
 
-      .. warning:: As of Pyramid 1.1, assignment to ``response_*`` attrs are
-         deprecated.  Assigning to one will cause a deprecation warning to be
-         emitted.  Instead of assigning ``response_*`` attributes to the
-         request, use API of the the :attr:`pyramid.request.Request.response`
-         object (exposed to view code as ``request.response``) to influence
-         response behavior.
-
-      You can set attributes on a :class:`pyramid.request.Request` which will
-      influence the behavor of *rendered* responses (views which use a
-      :term:`renderer` and which don't directly return a response).  These
-      attributes begin with ``response_``, such as ``response_headerlist``. If
-      you need to influence response values from a view that uses a renderer
-      (such as the status code, a header, the content type, etc) see,
-      :ref:`response_prefixed_attrs`.
+      In Pyramid 1.0, you could set attributes on a
+      :class:`pyramid.request.Request` which influenced the behavor of
+      *rendered* responses (views which use a :term:`renderer` and which
+      don't directly return a response).  These attributes began with
+      ``response_``, such as ``response_headerlist``. If you needed to
+      influence response values from a view that uses a renderer (such as the
+      status code, a header, the content type, etc) you would set these
+      attributes.  See :ref:`response_prefixed_attrs` for further discussion.
+      As of Pyramid 1.1, assignment to ``response_*`` attrs are deprecated.
+      Assigning to one is still supported but will cause a deprecation
+      warning to be emitted, and eventually the feature will be removed.  For
+      new code, instead of assigning ``response_*`` attributes to the
+      request, use API of the the :attr:`pyramid.request.Request.response`
+      object (exposed to view code as ``request.response``) to influence
+      rendered response behavior.
 
 .. note::