``config.add_translation_dirs``, the directories were inserted into the beginning of the directory list in the wrong order: they were inserted in the reverse of the order they were provided in the ``*specs`` list (items later in the list trumped ones earlier in the list). This is now fixed. Note however, that later calls to ``config.add_translation_dirs`` continue to insert directories into the beginning of the list of translation directories created by earlier calls. This means that the same translation found in a directory added via ``add_translation_dirs`` later in the configuration process will be found before one added earlier via a separate call to ``add_translation_dirs`` in the configuration process.
``environ['repoze.bfg.message']`` when it caught a view-related exception for backwards compatibility with :mod:`repoze.bfg` during error handling. It did this by using code that looked like so:: # "why" is an exception object try: msg = why except: msg = '' environ['repoze.bfg.message'] = msg Use of the value ``environ['repoze.bfg.message']`` was docs-deprecated in Pyramid 1.0. Our standing policy is to not remove features after a deprecation for two full major releases, so this code was originally slated to be removed in Pyramid 1.2. However, computing the ``repoze.bfg.message`` value was the source of at least one bug found in the wild (#199), and there isn't a foolproof way to both preserve backwards compatibility and to fix the bug. Therefore, the code which sets the value has been removed in this release. Code in exception views which relies on this value's presence in the environment should now use the ``exception`` attribute of the request (e.g. ``request.exception``) to retrieve the message instead of relying on ``request.environ['repoze.bfg.message']``. Closes #199.
- The ``pyramid.httpexceptions`` classes named ``HTTPFound``, ``HTTPMultipleChoices``, ``HTTPMovedPermanently``, ``HTTPSeeOther``, ``HTTPUseProxy``, and ``HTTPTemporaryRedirect`` now accept ``location`` as their first positional argument rather than ``detail``. This means that you can do, e.g. ``return pyramid.httpexceptions.HTTPFound('http://foo')`` rather than ``return pyramid.httpexceptions.HTTPFound(location='http//foo')`` (the latter will of course continue to work).
exception responses. - Add note about why we've created a shadow exception hierarchy parallel to that of webob.exc.
should be used instead of the ``pyramid.view.is_response`` function, which has been deprecated. - Deprecated ``pyramid.view.is_response`` function in favor of (newly-added) ``pyramid.request.Request.is_response`` method. Determining if an object is truly a valid response object now requires access to the registry, which is only easily available as a request attribute. The ``pyramid.view.is_response`` function will still work until it is removed, but now may return an incorrect answer under some (very uncommon) circumstances.
- Fix Configurator docstring wrt exception responses. - Speed up registry.queryAdapterOrSelf
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.
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.
``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
- The ``pyramid.request.Request`` class now has a ``ResponseClass`` interface which points at ``pyramid.response.Response``. - The ``pyramid.request.Response`` class now has a ``RequestClass`` interface which points at ``pyramid.response.Request``. - ``pyramid.response.Response`` is now a *subclass* of ``webob.response.Response``. It also inherits from the built-in Python ``Exception`` class and implements the ``pyramid.interfaces.IExceptionResponse`` class so it can be raised as an exception from view code.
``pyramid.httpexceptions.redirect``. - 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 ``webob.exc.HTTPException``. - 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).
argument. If this argument is ``True``, the added route will never be considered for matching when a request is handled. Instead, it will only be useful for URL generation via ``route_url`` and ``route_path``. See the section entitled "Static Routes" in the URL Dispatch narrative chapter for more information.
…ST``) as interface API documentation.
"traverser" (e.g. an object that implements ``pyramid.interfaces.ITraverser`` such as an instance of ``pyramid.traversal.ResourceTreeTraverser``) as its ``request`` argument now causes a deprecation warning to be emitted. Consumer code should pass a ``request`` object instead. The fact that passing an environ dict is permitted has been documentation-deprecated since ``repoze.bfg`` 1.1, and this capability will be removed entirely in a future version. - The following (undocumented, dictionary-like) methods of the ``pyramid.request.Request`` object have been deprecated: ``__contains__``, ``__delitem__``, ``__getitem__``, ``__iter__``, ``__setitem__``, ``get``, ``has_key``, ``items``, ``iteritems``, ``itervalues``, ``keys``, ``pop``, ``popitem``, ``setdefault``, ``update``, and ``values``. Usage of any of these methods will cause a deprecation warning to be emitted. These methods were added for internal compatibility in ``repoze.bfg`` 1.1 (code that currently expects a request object expected an environ object in BFG 1.0 and before). In a future version, these methods will be removed entirely.
``webob.request.Request`` and implemented ``__getattr__``, ``__setattr__`` and ``__delattr__`` itself in order to overidde "adhoc attr" WebOb behavior where attributes of the request are stored in the environ. Now, ``pyramid.request.Request`` object inherits from (the more recent) ``webob.request.BaseRequest`` instead of ``webob.request.Request``, which provides the same behavior. ``pyramid.request.Request`` no longer implements its own ``__getattr__``, ``__setattr__`` or ``__delattr__`` as a result.
- Modify documentation for cross-referencing. - Use add_view(viewname) syntax rather than add_view(view=viewname) syntax for normalization. - Use warnings.warn rather than zope.deprecated in order to make testing easier. - Move tests which test deprecated methods of configurator to a separate test case.