- Pyramid now expects Response objects to have a __call__

  method which implements the WSGI application interface
  instead of the three webob attrs status, headerlist
  and app_iter.  Backwards compatibility exists for
  code which returns response objects that do not
  have a __call__.

- pyramid.response.Response is no longer an exception
  (and therefore cannot be raised in order to generate
  a response).

- Changed my mind about moving stuff from pyramid.httpexceptions
  to pyramid.response.  The stuff I moved over has been moved
  back to pyramid.httpexceptions.

21 files changed, 220 insertions, 216 deletions

diff --git a/docs/api/httpexceptions.rst b/docs/api/httpexceptions.rst
index 73da4126b..325d5af03 100644
--- a/docs/api/httpexceptions.rst
+++ b/docs/api/httpexceptions.rst
@@ -5,16 +5,14 @@
 
 .. automodule:: pyramid.httpexceptions
 
-  .. autofunction:: abort
-
-  .. autofunction:: redirect
-
   .. attribute:: status_map
 
      A mapping of integer status code to exception class (eg. the
      integer "401" maps to
      :class:`pyramid.httpexceptions.HTTPUnauthorized`).
 
+  .. autofunction:: responsecode
+
   .. autoclass:: HTTPException
 
   .. autoclass:: HTTPOk
diff --git a/docs/api/response.rst b/docs/api/response.rst
index c545b4977..e67b15568 100644
--- a/docs/api/response.rst
+++ b/docs/api/response.rst
@@ -8,3 +8,4 @@
 .. autoclass:: Response
    :members:
    :inherited-members:
+
diff --git a/docs/glossary.rst b/docs/glossary.rst
index dbab331c1..079a069b4 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -594,7 +594,7 @@ Glossary
 
    Not Found view
       An :term:`exception view` invoked by :app:`Pyramid` when the
-      developer explicitly raises a ``pyramid.response.HTTPNotFound``
+      developer explicitly raises a ``pyramid.httpexceptions.HTTPNotFound``
       exception from within :term:`view` code or :term:`root factory`
       code, or when the current request doesn't match any :term:`view
       configuration`.  :app:`Pyramid` provides a default
@@ -604,7 +604,7 @@ Glossary
    Forbidden view
       An :term:`exception view` invoked by :app:`Pyramid` when the
       developer explicitly raises a
-      ``pyramid.response.HTTPForbidden`` exception from within
+      ``pyramid.httpexceptions.HTTPForbidden`` exception from within
       :term:`view` code or :term:`root factory` code, or when the
       :term:`view configuration` and :term:`authorization policy`
       found for a request disallows a particular view invocation.
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index aa151d281..b6a781417 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -21,7 +21,7 @@ configuration.
 
 The :term:`not found view` callable is a view callable like any other.  The
 :term:`view configuration` which causes it to be a "not found" view consists
-only of naming the :exc:`pyramid.response.HTTPNotFound` class as the
+only of naming the :exc:`pyramid.httpexceptions.HTTPNotFound` class as the
 ``context`` of the view configuration.
 
 If your application uses :term:`imperative configuration`, you can replace
@@ -31,7 +31,7 @@ method to register an "exception view":
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import HTTPNotFound
+   from pyramid.httpexceptions import HTTPNotFound
    from helloworld.views import notfound_view
    config.add_view(notfound_view, context=HTTPNotFound)
 
@@ -42,22 +42,22 @@ Like any other view, the notfound view must accept at least a ``request``
 parameter, or both ``context`` and ``request``.  The ``request`` is the
 current :term:`request` representing the denied action.  The ``context`` (if
 used in the call signature) will be the instance of the
-:exc:`~pyramid.response.HTTPNotFound` exception that caused the view to be
-called.
+:exc:`~pyramid.httpexceptions.HTTPNotFound` exception that caused the view to
+be called.
 
 Here's some sample code that implements a minimal NotFound view callable:
 
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import HTTPNotFound
+   from pyramid.httpexceptions import HTTPNotFound
 
    def notfound_view(request):
        return HTTPNotFound()
 
 .. note:: When a NotFound view callable is invoked, it is passed a
    :term:`request`.  The ``exception`` attribute of the request will be an
-   instance of the :exc:`~pyramid.response.HTTPNotFound` exception that
+   instance of the :exc:`~pyramid.httpexceptions.HTTPNotFound` exception that
    caused the not found view to be called.  The value of
    ``request.exception.args[0]`` will be a value explaining why the not found
    error was raised.  This message will be different when the
@@ -67,8 +67,9 @@ Here's some sample code that implements a minimal NotFound view callable:
 .. warning:: When a NotFound view callable accepts an argument list as
    described in :ref:`request_and_context_view_definitions`, the ``context``
    passed as the first argument to the view callable will be the
-   :exc:`~pyramid.response.HTTPNotFound` exception instance.  If available,
-   the resource context will still be available as ``request.context``.
+   :exc:`~pyramid.httpexceptions.HTTPNotFound` exception instance.  If
+   available, the resource context will still be available as
+   ``request.context``.
 
 .. index::
    single: forbidden view
@@ -85,7 +86,7 @@ the view which generates it can be overridden as necessary.
 
 The :term:`forbidden view` callable is a view callable like any other.  The
 :term:`view configuration` which causes it to be a "not found" view consists
-only of naming the :exc:`pyramid.response.HTTPForbidden` class as the
+only of naming the :exc:`pyramid.httpexceptions.HTTPForbidden` class as the
 ``context`` of the view configuration.
 
 You can replace the forbidden view by using the
@@ -96,7 +97,7 @@ view":
    :linenos:
 
    from helloworld.views import forbidden_view
-   from pyramid.response import HTTPForbidden
+   from pyramid.httpexceptions import HTTPForbidden
    config.add_view(forbidden_view, context=HTTPForbidden)
 
 Replace ``helloworld.views.forbidden_view`` with a reference to the Python
@@ -122,8 +123,8 @@ Here's some sample code that implements a minimal forbidden view:
 
 .. note:: When a forbidden view callable is invoked, it is passed a
    :term:`request`.  The ``exception`` attribute of the request will be an
-   instance of the :exc:`~pyramid.response.HTTPForbidden` exception that
-   caused the forbidden view to be called.  The value of
+   instance of the :exc:`~pyramid.httpexceptions.HTTPForbidden` exception
+   that caused the forbidden view to be called.  The value of
    ``request.exception.args[0]`` will be a value explaining why the forbidden
    was raised.  This message will be different when the
    ``debug_authorization`` environment setting is true than it is when it is
@@ -532,10 +533,10 @@ Changing How Pyramid Treats Response Objects
 It is possible to control how the Pyramid :term:`router` calls the WSGI
 ``start_response`` callable and obtains the WSGI ``app_iter`` based on
 adapting the response object to the :class: `pyramid.interfaces.IResponder`
-interface.  The default ``IResponder`` uses the three attributes ``status``,
-``headerlist``, and ``app_iter`` attached to the response object, and calls
-``start_response`` with the status and headerlist, returning the
-``app_iter``.  To override the responder::
+interface.  The default responder uses the ``__call__`` method of a response
+object, passing it the WSGI environ and the WSGI ``start_response`` callable
+(the response is assumed to be a WSGI application).  To override the
+responder::
 
      from pyramid.interfaces import IResponder
      from pyramid.response import Response
@@ -545,8 +546,9 @@ interface.  The default ``IResponder`` uses the three attributes ``status``,
                                      IResponder, name='')
 
 Overriding makes it possible to reuse response object implementations which
-have, for example, their own ``__call__`` expected to be used as a WSGI
-application (like :class:`pyramid.response.Response`), e.g.:
+have, for example, the ``app_iter``, ``headerlist`` and ``status`` attributes
+of an object returned as a response instead of trying to use the object's
+``__call__`` method::
 
      class MyResponder(object):
          def __init__(self, response):
@@ -554,8 +556,8 @@ application (like :class:`pyramid.response.Response`), e.g.:
              self.response = response
          def __call__(self, request, start_response):
              """ Call start_response and return an app_iter """
-             app_iter = self.response(request.environ, start_response)
-             return app_iter
+             start_response(self.response.status, self.response.headerlist)
+             return self.response.app_iter
 
 .. index::
    single: view mapper
diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index c7a3d7837..99ee14908 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -11,7 +11,6 @@ Response interface, :app:`Pyramid` will attempt to use a
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import Response
    from pyramid.view import view_config
 
    @view_config(renderer='json')
@@ -77,39 +76,52 @@ templating language to render a dictionary to a response.  Additional
 renderers can be added by developers to the system as necessary (see
 :ref:`adding_and_overriding_renderers`).
 
-Views which use a renderer can vary non-body response attributes (such as
-headers and the HTTP status code) by attaching a property to the
-``request.response`` attribute See :ref:`request_response_attr`.
+Views which use a renderer and return a non-Response value can vary non-body
+response attributes (such as headers and the HTTP status code) by attaching a
+property to the ``request.response`` attribute See
+:ref:`request_response_attr`.
 
 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
+returns a Response object directly, any renderer associated with the view
 configuration is ignored, and the response is passed back to :app:`Pyramid`
 unchanged.  For example, if your view callable returns an instance of the
-:class:`pyramid.response.HTTPFound` class as a response, no renderer will be
-employed.
+:class:`pyramid.response.Response` class as a response, no renderer
+will be employed.
 
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import HTTPFound
+   from pyramid.response import Response
+   from pyramid.view import view_config
 
+   @view_config(renderer='json')
    def view(request):
-       return HTTPFound(location='http://example.com') # any renderer avoided
+       return Response('OK') # json renderer avoided
 
-Likewise for a "plain old response":
+Likewise for an :term:`HTTP exception` response:
 
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import Response
+   from pyramid.httpexceptions import HTTPNotFound
+   from pyramid.view import view_config
 
+   @view_config(renderer='json')
    def view(request):
-       return Response('OK') # any renderer avoided
+       return HTTPFound(location='http://example.com') # json renderer avoided
 
-Mutations to ``request.response`` in views which return a Response object
-like this directly (unless that response *is* ``request.response``) will be
-ignored.
+You can of course also return the ``request.response`` attribute instead to
+avoid rendering:
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.view import view_config
+
+   @view_config(renderer='json')
+   def view(request):
+       request.response.body = 'OK'
+       return request.response # json renderer avoided
 
 .. index::
    single: renderers (built-in)
@@ -377,6 +389,31 @@ callable that uses a renderer, assign the ``status`` attribute to the
        request.response.status = '404 Not Found'
        return {'URL':request.URL}
 
+Note that mutations of ``request.response`` in views which return a Response
+object directly will have no effect unless the response object returned *is*
+``request.response``.  For example, the following example calls
+``request.response.set_cookie``, but this call will have no effect, because a
+different Response object is returned.
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.response import Response
+
+   def view(request):
+       request.response.set_cookie('abc', '123') # this has no effect
+       return Response('OK') # because we're returning a different response
+
+If you mutate ``request.response`` and you'd like the mutations to have an
+effect, you must return ``request.response``:
+
+.. code-block:: python
+   :linenos:
+
+   def view(request):
+       request.response.set_cookie('abc', '123')
+       return request.response
+
 For more information on attributes of the request, see the API documentation
 in :ref:`request_module`.  For more information on the API of
 ``request.response``, see :class:`pyramid.response.Response`.
diff --git a/docs/narr/router.rst b/docs/narr/router.rst
index 44fa9835b..30d54767e 100644
--- a/docs/narr/router.rst
+++ b/docs/narr/router.rst
@@ -82,8 +82,8 @@ processing?
    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), :app:`Pyramid` raises a
-   :class:`~pyramid.response.HTTPNotFound` exception, which is meant to be
-   caught by a surrounding exception handler.
+   :class:`~pyramid.httpexceptions.HTTPNotFound` exception, which is meant to
+   be caught by a surrounding :term:`exception view`.
 
 #. If a view callable was found, :app:`Pyramid` attempts to call
    the view function.
@@ -95,13 +95,13 @@ processing?
    information in the request and security information attached to the
    context.  If it returns ``True``, :app:`Pyramid` calls the view callable
    to obtain a response.  If it returns ``False``, it raises a
-   :class:`~pyramid.response.HTTPForbidden` exception, which is meant to be
-   called by a surrounding exception handler.
+   :class:`~pyramid.httpexceptions.HTTPForbidden` exception, which is meant
+   to be called by a surrounding :term:`exception view`.
 
 #. If any exception was raised within a :term:`root factory`, by
    :term:`traversal`, by a :term:`view callable` or by :app:`Pyramid` itself
-   (such as when it raises :class:`~pyramid.response.HTTPNotFound` or
-   :class:`~pyramid.response.HTTPForbidden`), the router catches the
+   (such as when it raises :class:`~pyramid.httpexceptions.HTTPNotFound` or
+   :class:`~pyramid.httpexceptions.HTTPForbidden`), the router catches the
    exception, and attaches it to the request as the ``exception`` attribute.
    It then attempts to find a :term:`exception view` for the exception that
    was caught.  If it finds an exception view callable, that callable is
diff --git a/docs/narr/testing.rst b/docs/narr/testing.rst
index 862eda9f0..05e851fde 100644
--- a/docs/narr/testing.rst
+++ b/docs/narr/testing.rst
@@ -191,7 +191,7 @@ function.
    :linenos:
 
    from pyramid.security import has_permission
-   from pyramid.response import HTTPForbidden
+   from pyramid.httpexceptions import HTTPForbidden
 
    def view_fn(request):
        if not has_permission('edit', request.context, request):
@@ -230,7 +230,7 @@ without needing to invoke the actual application configuration implied by its
            testing.tearDown()
        
        def test_view_fn_forbidden(self):
-           from pyramid.response import HTTPForbidden
+           from pyramid.httpexceptions import HTTPForbidden
            from my.package import view_fn
            self.config.testing_securitypolicy(userid='hank', 
                                               permissive=False)
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index e5228b81e..f94ed3ba8 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -917,7 +917,7 @@ the application's startup configuration, adding the following stanza:
    :linenos:
 
    config.add_view('pyramid.view.append_slash_notfound_view', 
-                   context='pyramid.response.HTTPNotFound')
+                   context='pyramid.httpexceptions.HTTPNotFound')
 
 See :ref:`view_module` and :ref:`changing_the_notfound_view` for more
 information about the slash-appending not found view and for a more general
@@ -945,7 +945,7 @@ view as the first argument to its constructor.  For instance:
 .. code-block:: python
      :linenos:
 
-     from pyramid.response import HTTPNotFound
+     from pyramid.httpexceptions import HTTPNotFound
      from pyramid.view import AppendSlashNotFoundViewFactory
 
      def notfound_view(context, request):
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 73a7c2e2a..990828f80 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -230,29 +230,29 @@ implements the :term:`Response` interface is to return a
    def view(request):
        return Response('OK')
 
-You don't need to always use :class:`~pyramid.response.Response` to represent
-a 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.response.HTTPFound` is also a valid response object
-(see :ref:`http_exceptions` and ref:`http_redirect`).  A view can actually
-return any object that has the following attributes.
-
-status
-  The HTTP status code (including the name) for the response as a string.
-  E.g. ``200 OK`` or ``401 Unauthorized``.
-
-headerlist
-  A sequence of tuples representing the list of headers that should be
-  set in the response.  E.g. ``[('Content-Type', 'text/html'),
-  ('Content-Length', '412')]``
-
-app_iter
-  An iterable representing the body of the response.  This can be a
-  list, e.g. ``['<html><head></head><body>Hello
-  world!</body></html>']`` or it can be a file-like object, or any
-  other sort of iterable.
-
-These attributes form the structure of the "Pyramid Response interface".
+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`).
 
 .. index::
    single: view exceptions
@@ -269,40 +269,8 @@ logged there.
 
 However, for convenience, a special set of exceptions exists.  When one of
 these exceptions is raised within a view callable, it will always cause
-:app:`Pyramid` to generate a response.  Two categories of special exceptions
-exist: internal exceptions and HTTP exceptions.
-
-Internal Exceptions
-~~~~~~~~~~~~~~~~~~~
-
-:exc:`pyramid.response.HTTPNotFound` and
-:exc:`pyramid.response.HTTPForbidden` are exceptions often raised by Pyramid
-itself when it (respectively) cannot find a view to service a request or when
-authorization was forbidden by a security policy.  However, they can also be
-raised by application developers.
-
-If :exc:`~pyramid.response.HTTPNotFound` is raised within view code, the
-result of the :term:`Not Found View` will be returned to the user agent which
-performed the request.
-
-If :exc:`~pyramid.response.HTTPForbidden` is raised within view code, the
-result of the :term:`Forbidden View` will be returned to the user agent which
-performed the request.
-
-Both are exception classes which accept a single positional constructor
-argument: a ``message``.  In all cases, the message provided to the exception
-constructor is made available to the view which :app:`Pyramid` invokes as
-``request.exception.args[0]``.
-
-An example:
-
-.. code-block:: python
-   :linenos:
-
-    from pyramid.response import HTTPNotFound
-
-    def aview(request):
-        raise HTTPNotFound('not found!')
+:app:`Pyramid` to generate a response.  These are known as :term:`HTTP
+exception` objects.
 
 .. index::
    single: HTTP exceptions
@@ -312,54 +280,77 @@ An example:
 HTTP Exceptions
 ~~~~~~~~~~~~~~~
 
-All classes documented in the :mod:`pyramid.response` module as inheriting
-from the :class:`pryamid.response.Response` object implement the
-:term:`Response` interface; an instance of any of these classes can be
-returned or raised from within a view.  The instance will be used as as the
-view's response.
+All classes documented in the :mod:`pyramid.httpexceptions` module documented
+as inheriting from the :class:`pryamid.httpexceptions.HTTPException` are
+:term:`http exception` objects.  An instances of an HTTP exception object may
+either be *returned* or *raised* from within view code.  In either case
+(return or raise) the instance will be used as as the view's response.
 
-For example, the :class:`pyramid.response.HTTPUnauthorized` exception
+For example, the :class:`pyramid.httpexceptions.HTTPUnauthorized` exception
 can be raised.  This will cause a response to be generated with a ``401
 Unauthorized`` status:
 
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import HTTPUnauthorized
+   from pyramid.httpexceptions import HTTPUnauthorized
 
    def aview(request):
        raise HTTPUnauthorized()
 
-A shortcut for importing and raising an HTTP exception is the
-:func:`pyramid.response.abort` function.  This function accepts an HTTP
-status code and raises the corresponding HTTP exception.  For example, to
-raise HTTPUnauthorized, instead of the above, you could do:
+An HTTP exception, instead of being raised, can alternately be *returned*
+(HTTP exceptions are also valid response objects):
 
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import abort
+   from pyramid.httpexceptions import HTTPUnauthorized
 
    def aview(request):
-       abort(401)
-
-This is the case because ``401`` is the HTTP status code for "HTTP
-Unauthorized".  Therefore, ``abort(401)`` is functionally equivalent to
-``raise HTTPUnauthorized()``.  Other exceptions in
-:mod:`pyramid.response` can be raised via
-:func:`pyramid.response.abort` as well, as long as the status code
-associated with the exception is provided to the function.
+       return HTTPUnauthorized()
 
-An HTTP exception, instead of being raised, can alternately be *returned*
-(HTTP exceptions are also valid response objects):
+A shortcut for creating an HTTP exception is the
+:func:`pyramid.httpexceptions.responsecode` function.  This function accepts
+an HTTP status code and returns the corresponding HTTP exception.  For
+example, instead of importing and constructing a
+:class:`~pyramid.httpexceptions.HTTPUnauthorized` response object, you can
+use the :func:`~pyramid.httpexceptions.responsecode` function to construct
+and return the same object.
 
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import HTTPUnauthorized
+   from pyramid.httpexceptions import responsecode
 
    def aview(request):
-       return HTTPUnauthorized()
+       raise responsecode(401)
+
+This is the case because ``401`` is the HTTP status code for "HTTP
+Unauthorized".  Therefore, ``raise responsecode(401)`` is functionally
+equivalent to ``raise HTTPUnauthorized()``.  Documentation which maps each
+HTTP response code to its purpose and its associated HTTP exception object is
+provided within :mod:`pyramid.httpexceptions`.
+
+How Pyramid Uses HTTP Exceptions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+HTTP exceptions are meant to be used directly by application application
+developers.  However, Pyramid itself will raise two HTTP exceptions at
+various points during normal operations:
+:exc:`pyramid.httpexceptions.HTTPNotFound` and
+:exc:`pyramid.httpexceptions.HTTPForbidden`.  Pyramid will raise the
+:exc:`~pyramid.httpexceptions.HTTPNotFound` exception are raised when it
+cannot find a view to service a request.  Pyramid will raise the
+:exc:`~pyramid.httpexceptions.Forbidden` exception or when authorization was
+forbidden by a security policy.
+
+If :exc:`~pyramid.httpexceptions.HTTPNotFound` is raised by Pyramid itself or
+within view code, the result of the :term:`Not Found View` will be returned
+to the user agent which performed the request.
+
+If :exc:`~pyramid.httpexceptions.HTTPForbidden` is raised by Pyramid itself
+within view code, the result of the :term:`Forbidden View` will be returned
+to the user agent which performed the request.
 
 .. index::
    single: exception views
@@ -369,11 +360,10 @@ An HTTP exception, instead of being raised, can alternately be *returned*
 Custom Exception Views
 ----------------------
 
-The machinery which allows :exc:`~pyramid.response.HTTPNotFound`,
-:exc:`~pyramid.response.HTTPForbidden` and other responses to be used as
-exceptions and caught by specialized views as described in
-:ref:`special_exceptions_in_callables` can also be used by application
-developers to convert arbitrary exceptions to responses.
+The machinery which allows HTTP exceptions to be raised and caught by
+specialized views as described in :ref:`special_exceptions_in_callables` can
+also be used by application developers to convert arbitrary exceptions to
+responses.
 
 To register a view that should be called whenever a particular exception is
 raised from with :app:`Pyramid` view code, use the exception class or one of
@@ -409,8 +399,8 @@ raises a ``helloworld.exceptions.ValidationFailure`` exception:
 Assuming that a :term:`scan` was run to pick up this view registration, this
 view callable will be invoked whenever a
 ``helloworld.exceptions.ValidationFailure`` is raised by your application's
-view code.  The same exception raised by a custom root factory or a custom
-traverser is also caught and hooked.
+view code.  The same exception raised by a custom root factory, a custom
+traverser, or a custom view or route predicate is also caught and hooked.
 
 Other normal view predicates can also be used in combination with an
 exception view registration:
@@ -458,57 +448,34 @@ Exception views can be configured with any view registration mechanism:
 Using a View Callable to Do an HTTP Redirect
 --------------------------------------------
 
-Two methods exist to redirect to another URL from within a view callable: a
-short form and a long form.  The short form should be preferred when
-possible.
-
-Short Form
-~~~~~~~~~~
-
-You can issue an HTTP redirect from within a view callable by using the
-:func:`pyramid.response.redirect` function.  This function raises an
-:class:`pyramid.response.HTTPFound` exception (a "302"), which is caught by
-the default exception response handler and turned into a response.
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.response import redirect
-
-   def myview(request):
-       redirect('http://example.com')
-
-Long Form
-~~~~~~~~~
-
-You can issue an HTTP redirect from within a view "by hand" instead of
-relying on the :func:`pyramid.response.redirect` function to do it for
-you.
+You can issue an HTTP redirect by using the
+:class:`pyramid.httpexceptions.HTTPFound` class.  Raising or returning an
+instance of this class will cause the client to receive a "302 Found"
+response.
 
-To do so, you can *return* a :class:`pyramid.response.HTTPFound`
+To do so, you can *return* a :class:`pyramid.httpexceptions.HTTPFound`
 instance.
 
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import HTTPFound
+   from pyramid.httpexceptions import HTTPFound
 
    def myview(request):
        return HTTPFound(location='http://example.com')
 
-Or, alternately, you can *raise* an HTTPFound exception instead of returning
-one.
+Alternately, you can *raise* an HTTPFound exception instead of returning one.
 
 .. code-block:: python
    :linenos:
 
-   from pyramid.response import HTTPFound
+   from pyramid.httpexceptions import HTTPFound
 
    def myview(request):
        raise HTTPFound(location='http://example.com')
 
-The above form of generating a response by raising HTTPFound is completely
-equivalent to ``redirect('http://example.com')``.
+When the instance is raised, it is caught by the default :term:`exception
+response` handler and turned into a response.
 
 .. index::
    single: unicode, views, and forms
diff --git a/docs/narr/webob.rst b/docs/narr/webob.rst
index 6cd9418ce..70ab5eea8 100644
--- a/docs/narr/webob.rst
+++ b/docs/narr/webob.rst
@@ -362,20 +362,21 @@ 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 :app:`Pyramid`, should be imported from the
-:mod:`pyramid.response` module.  This import location contains subclasses and
-replacements that mirror those in the original ``webob.exc``.
+:mod:`pyramid.httpexceptions` module.  This import location contains
+subclasses and replacements that mirror those in the original ``webob.exc``.
 
-Each class is named ``pyramid.response.HTTP*``, where ``*`` is the reason for
-the error.  For instance, :class:`pyramid.response.HTTPNotFound`.  It
-subclasses :class:`pyramid.Response`, so you can manipulate the instances in
-the same way.  A typical example is:
+Each class is named ``pyramid.httpexceptions.HTTP*``, where ``*`` is the
+reason for the error.  For instance,
+:class:`pyramid.httpexceptions.HTTPNotFound` subclasses
+:class:`pyramid.Response`, so you can manipulate the instances in the same
+way.  A typical example is:
 
 .. ignore-next-block
 .. code-block:: python
     :linenos:
 
-    from pyramid.response import HTTPNotFound
-    from pyramid.response import HTTPMovedPermanently
+    from pyramid.httpexceptions import HTTPNotFound
+    from pyramid.httpexceptions import HTTPMovedPermanently
 
     response = HTTPNotFound('There is no such resource')
     # or:
@@ -385,7 +386,7 @@ More Details
 ++++++++++++
 
 More details about the response object API are available in the
-:mod:`pyramid.response` documentation.  More details about exception responses
-are in the :mod:`pyramid.response` API documentation.  The `WebOb
-documentation <http://pythonpaste.org/webob>`_ is also useful.
+:mod:`pyramid.response` documentation.  More details about exception
+responses are in the :mod:`pyramid.httpexceptions` API documentation.  The
+`WebOb documentation <http://pythonpaste.org/webob>`_ is also useful.
 
diff --git a/docs/tutorials/wiki/authorization.rst b/docs/tutorials/wiki/authorization.rst
index 3b102958e..de5c9486d 100644
--- a/docs/tutorials/wiki/authorization.rst
+++ b/docs/tutorials/wiki/authorization.rst
@@ -131,17 +131,17 @@ callable.
 The first view configuration decorator configures the ``login`` view callable
 so it will be invoked when someone visits ``/login`` (when the context is a
 Wiki and the view name is ``login``).  The second decorator (with context of
-``pyramid.response.HTTPForbidden``) specifies a :term:`forbidden view`.  This
-configures our login view to be presented to the user when :app:`Pyramid`
-detects that a view invocation can not be authorized.  Because we've
-configured a forbidden view, the ``login`` view callable will be invoked
-whenever one of our users tries to execute a view callable that they are not
-allowed to invoke as determined by the :term:`authorization policy` in use.
-In our application, for example, this means that if a user has not logged in,
-and he tries to add or edit a Wiki page, he will be shown the login form.
-Before being allowed to continue on to the add or edit form, he will have to
-provide credentials that give him permission to add or edit via this login
-form.
+``pyramid.httpexceptions.HTTPForbidden``) specifies a :term:`forbidden view`.
+This configures our login view to be presented to the user when
+:app:`Pyramid` detects that a view invocation can not be authorized.  Because
+we've configured a forbidden view, the ``login`` view callable will be
+invoked whenever one of our users tries to execute a view callable that they
+are not allowed to invoke as determined by the :term:`authorization policy`
+in use.  In our application, for example, this means that if a user has not
+logged in, and he tries to add or edit a Wiki page, he will be shown the
+login form.  Before being allowed to continue on to the add or edit form, he
+will have to provide credentials that give him permission to add or edit via
+this login form.
 
 Changing Existing Views
 ~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/tutorials/wiki/definingviews.rst b/docs/tutorials/wiki/definingviews.rst
index ea8842294..b6c083bbf 100644
--- a/docs/tutorials/wiki/definingviews.rst
+++ b/docs/tutorials/wiki/definingviews.rst
@@ -83,10 +83,10 @@ No renderer is necessary when a view returns a response object.
 
 The ``view_wiki`` view callable always redirects to the URL of a Page
 resource named "FrontPage".  To do so, it returns an instance of the
-:class:`pyramid.response.HTTPFound` class (instances of which implement the
-WebOb :term:`response` interface).  The :func:`pyramid.url.resource_url` API.
-:func:`pyramid.url.resource_url` constructs a URL to the ``FrontPage`` page
-resource (e.g. ``http://localhost:6543/FrontPage``), and uses it as the
+:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement
+the WebOb :term:`response` interface).  The :func:`pyramid.url.resource_url`
+API.  :func:`pyramid.url.resource_url` constructs a URL to the ``FrontPage``
+page resource (e.g. ``http://localhost:6543/FrontPage``), and uses it as the
 "location" of the HTTPFound response, forming an HTTP redirect.
 
 The ``view_page`` view function
diff --git a/docs/tutorials/wiki/src/authorization/tutorial/login.py b/docs/tutorials/wiki/src/authorization/tutorial/login.py
index 822b19b9e..334115880 100644
--- a/docs/tutorials/wiki/src/authorization/tutorial/login.py
+++ b/docs/tutorials/wiki/src/authorization/tutorial/login.py
@@ -1,4 +1,4 @@
-from pyramid.response import HTTPFound
+from pyramid.httpexceptions import HTTPFound
 
 from pyramid.security import remember
 from pyramid.security import forget
@@ -9,7 +9,7 @@ from tutorial.security import USERS
 
 @view_config(context='tutorial.models.Wiki', name='login',
              renderer='templates/login.pt')
-@view_config(context='pyramid.response.HTTPForbidden',
+@view_config(context='pyramid.httpexceptions.HTTPForbidden',
              renderer='templates/login.pt')
 def login(request):
     login_url = resource_url(request.context, request, 'login')
diff --git a/docs/tutorials/wiki/src/authorization/tutorial/views.py b/docs/tutorials/wiki/src/authorization/tutorial/views.py
index 67550d58e..a83e17de4 100644
--- a/docs/tutorials/wiki/src/authorization/tutorial/views.py
+++ b/docs/tutorials/wiki/src/authorization/tutorial/views.py
@@ -1,7 +1,7 @@
 from docutils.core import publish_parts
 import re
 
-from pyramid.response import HTTPFound
+from pyramid.httpexceptions import HTTPFound
 from pyramid.url import resource_url
 from pyramid.view import view_config
 from pyramid.security import authenticated_userid
diff --git a/docs/tutorials/wiki/src/views/tutorial/views.py b/docs/tutorials/wiki/src/views/tutorial/views.py
index d72cbd3fd..42420f2fe 100644
--- a/docs/tutorials/wiki/src/views/tutorial/views.py
+++ b/docs/tutorials/wiki/src/views/tutorial/views.py
@@ -1,7 +1,7 @@
 from docutils.core import publish_parts
 import re
 
-from pyramid.response import HTTPFound
+from pyramid.httpexceptions import HTTPFound
 from pyramid.url import resource_url
 from pyramid.view import view_config
 
diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst
index 32e3c0b24..832f90b92 100644
--- a/docs/tutorials/wiki2/definingviews.rst
+++ b/docs/tutorials/wiki2/definingviews.rst
@@ -90,8 +90,8 @@ path to our "FrontPage".
    :language: python
 
 The ``view_wiki`` function returns an instance of the
-:class:`pyramid.response.HTTPFound` class (instances of which implement the
-WebOb :term:`response` interface), It will use the
+:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement
+the WebOb :term:`response` interface), It will use the
 :func:`pyramid.url.route_url` API to construct a URL to the ``FrontPage``
 page (e.g. ``http://localhost:6543/FrontPage``), and will use it as the
 "location" of the HTTPFound response, forming an HTTP redirect.
diff --git a/docs/tutorials/wiki2/src/authorization/tutorial/__init__.py b/docs/tutorials/wiki2/src/authorization/tutorial/__init__.py
index 42013622c..4cd84eda5 100644
--- a/docs/tutorials/wiki2/src/authorization/tutorial/__init__.py
+++ b/docs/tutorials/wiki2/src/authorization/tutorial/__init__.py
@@ -39,7 +39,7 @@ def main(global_config, **settings):
     config.add_view('tutorial.views.edit_page', route_name='edit_page',
                     renderer='tutorial:templates/edit.pt', permission='edit')
     config.add_view('tutorial.login.login',
-                    context='pyramid.response.HTTPForbidden',
+                    context='pyramid.httpexceptions.HTTPForbidden',
                     renderer='tutorial:templates/login.pt')
     return config.make_wsgi_app()
 
diff --git a/docs/tutorials/wiki2/src/authorization/tutorial/login.py b/docs/tutorials/wiki2/src/authorization/tutorial/login.py
index 2bc8a7201..7a1d1f663 100644
--- a/docs/tutorials/wiki2/src/authorization/tutorial/login.py
+++ b/docs/tutorials/wiki2/src/authorization/tutorial/login.py
@@ -1,4 +1,4 @@
-from pyramid.response import HTTPFound
+from pyramid.httpexceptions import HTTPFound
 from pyramid.security import remember
 from pyramid.security import forget
 from pyramid.url import route_url
diff --git a/docs/tutorials/wiki2/src/authorization/tutorial/views.py b/docs/tutorials/wiki2/src/authorization/tutorial/views.py
index ed441295c..5abd8391e 100644
--- a/docs/tutorials/wiki2/src/authorization/tutorial/views.py
+++ b/docs/tutorials/wiki2/src/authorization/tutorial/views.py
@@ -2,7 +2,7 @@ import re
 
 from docutils.core import publish_parts
 
-from pyramid.response import HTTPFound
+from pyramid.httpexceptions import HTTPFound
 from pyramid.security import authenticated_userid
 from pyramid.url import route_url
 
diff --git a/docs/tutorials/wiki2/src/views/tutorial/views.py b/docs/tutorials/wiki2/src/views/tutorial/views.py
index 80d817d99..b8896abe7 100644
--- a/docs/tutorials/wiki2/src/views/tutorial/views.py
+++ b/docs/tutorials/wiki2/src/views/tutorial/views.py
@@ -2,7 +2,7 @@ import re
 
 from docutils.core import publish_parts
 
-from pyramid.response import HTTPFound
+from pyramid.httpexceptions import HTTPFound
 from pyramid.url import route_url
 
 from tutorial.models import DBSession
diff --git a/docs/whatsnew-1.1.rst b/docs/whatsnew-1.1.rst
index 488328519..533ae3637 100644
--- a/docs/whatsnew-1.1.rst
+++ b/docs/whatsnew-1.1.rst
@@ -63,12 +63,6 @@ Default HTTP Exception View
   from within view code; when raised, this exception view will render the
   exception to a response.
 
-  New convenience functions named :func:`pyramid.httpexceptions.abort` and
-  :func:`pyramid.httpexceptions.redirect` perform the equivalent of their
-  Pylons brethren when an HTTP exception handler is registered.  These
-  functions take advantage of the newly registered exception view for
-  :exc:`webob.exc.HTTPException`.
-
   To allow for configuration of this feature, the :term:`Configurator` now
   accepts an additional keyword argument named ``httpexception_view``.  By
   default, this argument is populated with a default exception view function
@@ -81,6 +75,10 @@ Default HTTP Exception View
 Minor Feature Additions
 -----------------------
 
+- A function named :func:`pyramid.httpexceptions.responsecode` is a shortcut
+  that can be used to create HTTP exception response objects using an HTTP
+  integer status code.
+
 - Integers and longs passed as ``elements`` to
   :func:`pyramid.url.resource_url` or
   :meth:`pyramid.request.Request.resource_url` e.g. ``resource_url(context,
@@ -177,7 +175,7 @@ Deprecations and Behavior Differences
   expected an environ object in BFG 1.0 and before).  In a future version,
   these methods will be removed entirely.
 
-- A custom request factory is now required to return a response object that
+- A custom request factory is now required to return a request object that
   has a ``response`` attribute (or "reified"/lazy property) if they the
   request is meant to be used in a view that uses a renderer.  This
   ``response`` attribute should be an instance of the class