Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Jul 12, 2011
  1. @mcdonc

    add PyPy

    mcdonc authored
  2. @mcdonc

    bad reference

    mcdonc authored
Commits on Jul 11, 2011
  1. @mcdonc


    mcdonc authored
  2. @mmerickel
Commits on Jul 10, 2011
  1. @mcdonc
Commits on Jun 14, 2011
  1. @mcdonc
Commits on Jun 13, 2011
  1. @mcdonc

    - Remove IResponder abstraction in favor of more general IResponse

    mcdonc authored
    - 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.
Commits on Jun 11, 2011
  1. @mcdonc

    - Pyramid now expects Response objects to have a __call__

    mcdonc authored
      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.
Commits on Jun 4, 2011
  1. @mcdonc

    - It is now possible to control how the Pyramid router calls the WSGI

    mcdonc authored
      ``start_response`` callable and obtains the WSGI ``app_iter`` based on
      adapting the response object to the new ``pyramid.interfaces.IResponder``
      interface.  The default ``IResponder`` uses Pyramid 1.0's logic to do this.
      To override the responder::
         from pyramid.interfaces import IResponder
         from pyramid.response import Response
         from myapp import MyResponder
         config.registry.registerAdapter(MyResponder, (Response,),
                                         IResponder, name='')
      This makes it possible to reuse response object implementations which have,
      for example, their own ``__call__`` expected to be used as a WSGI
      application (like ``pyramid.response.Response``), e.g.:
         class MyResponder(object):
             def __init__(self, response):
                 """ Obtain a reference to the response """
                 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
Commits on Jun 3, 2011
  1. @Cito
Commits on May 31, 2011
  1. @mcdonc
Commits on May 16, 2011
  1. @mcdonc

    - Added API docs for ``pyramid.httpexceptions.abort`` and

    mcdonc authored
    - Added "HTTP Exceptions" section to Views narrative chapter including a
      description of ``pyramid.httpexceptions.abort``; adjusted redirect section
      to note ``pyramid.httpexceptions.redirect``.
    - A default exception view for the context ``webob.exc.HTTPException`` (aka
      ``pyramid.httpexceptions.HTTPException``) is now registered by default.
      This means that an instance of any exception class imported from
      ``pyramid.httpexceptions`` (such as ``HTTPFound``) can now be raised from
      within view code; when raised, this exception view will render the
      exception to a response.
    - New functions named ``pyramid.httpexceptions.abort`` and
      ``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
    - The Configurator now accepts an additional keyword argument named
      ``httpexception_view``.  By default, this argument is populated with a
      default exception view function that will be used when an HTTP exception is
      raised.  When ``None`` is passed for this value, an exception view for HTTP
      exceptions will not be registered.  Passing ``None`` returns the behavior
      of raising an HTTP exception to that of Pyramid 1.0 (the exception will
      propagate to middleware and to the WSGI server).
Commits on May 14, 2011
  1. @wichert

    Correct spelling of my name

    wichert authored
  2. @mcdonc
Commits on May 13, 2011
  1. @mcdonc

    - Added documentation for a "multidict" (e.g. the API of ``request.PO…

    mcdonc authored
    …ST``) as
      interface API documentation.
Commits on Apr 11, 2011
  1. @mcdonc

    pyramid_sqla -> akhet

    mcdonc authored
Commits on Mar 25, 2011
  1. @jayd3e

    It was decided that pyramid would undergo a terminology change.

    jayd3e authored
    'Paster templates' will now be refered to as 'scaffolds,' while
    'rendered templates' will remain as 'templates.'  I have changed
    the docs to reflect this change in terminology.
Commits on Jan 29, 2011
  1. @mcdonc
  2. @mcdonc

    - Moved "Using ZODB With ZEO" and "Using repoze.catalog Within Pyramid"

    mcdonc authored
      tutorials out of core documentation and into the Pyramid Tutorials site
  3. @mcdonc


    mcdonc authored
  4. @kyle-johnson
Commits on Jan 22, 2011
  1. @mcdonc

    add distutils entry

    mcdonc authored
Commits on Jan 21, 2011
  1. @mcdonc
  2. @mcdonc
Commits on Jan 19, 2011
  1. @mcdonc
Commits on Jan 18, 2011
  1. @mcdonc

    - Most references to ZCML in narrative chapters have been removed or

    mcdonc authored
      redirected to ``pyramid_zcml`` locations.
Commits on Jan 16, 2011
  1. @mcdonc

    use correct rendering

    mcdonc authored
Commits on Jan 8, 2011
  1. @mcdonc

    fix renderings

    mcdonc authored
Commits on Jan 3, 2011
  1. @mcdonc

    - Add a new API ``pyramid.url.current_route_url``, which computes a U…

    mcdonc authored
    …RL based
      on the "current" route (if any) and its matchdict values.
  2. @caseman
  3. @mcdonc

    fix rendering

    mcdonc authored
  4. @mcdonc
Commits on Jan 2, 2011
  1. @mcdonc

    - add a ``add_view_mapper`` API to Configurator. This API allows you …

    mcdonc authored
    …to add
      a named implementation of a ``pyramid.interfaces.IViewMapperFactory``
      interface.  Its name can be passed as a ``view_mapper`` argument to
      ``config.add_view``.  A view mapper allows objects that are meant to be
      used as view callables to have an arbitrary argument list and an arbitrary
      result.  This feature will be used by Pyramid extension developers, not by
    - New constructor argument to Configurator: ``default_view_mapper``.  Useful
      to create systems that have view callables with alternate default calling
    - ``view_mapper`` argument to ``add_view`` should now be a view mapper *name*
      rather than an implementation.
    - Add ``view_mapper`` argument to ``view_config`` decorator constructor.
    - Remove (non-API) function of named _map_view.
    - Fix docstring for ``decorator`` argument to add_view.
    - Factor invocation of view mapper into a viewderiver method.
    - Promote view rendering and decorating into viewderiver, out of view mapper.
    - Make requestonly into a function rather than a method of the default view
Commits on Dec 31, 2010
  1. @jahmad
Commits on Dec 26, 2010
  1. @mcdonc


    mcdonc authored
Something went wrong with that request. Please try again.