app's environ will no longer have (deprecated and potentially misleading) ``bfg.routes.matchdict`` or ``bfg.routes.route`` keys in it.
…Python 2/3 straddling support for Pyramid add-ons and development environments.
added a hide toc for glossary to prevent warnings
``add_finished_callback`` and ``add_response_callback`` methods.
…, and ``current_route_url`` functions in the ``pyramid.url`` package now delegate to a method on the request they've been passed, instead of the other way around. The pyramid.request.Request object now inherits from a mixin named pyramid.url.URLMethodsMixin to make this possible, and all url/path generation logic is embedded in this mixin. - Narrative and API documentation which used the ``route_url``, ``route_path``, ``resource_url``, ``static_url``, and ``current_route_url`` functions in the ``pyramid.url`` package have now been changed to use eponymous methods of the request instead.
…value will be ``None`` until an exception is caught by the Pyramid router, after which it will be the result of ``sys.exc_info()``.
…pper is used to wrap the found view callable before it is called by Pyramid's router. This is a feature usually only used by framework extensions, to provide, for example, view timing support. A view wrapper factory must be a callable which accepts three arguments: ``view_callable``, ``request``, and ``exc``. It must return a view callable. The view callable returned by the factory must implement the ``context, request`` view callable calling convention. For example:: import time def wrapper_factory(view_callable, request, exc): def wrapper(context, request): start = time.time() result = view_callable(context, request) end = time.time() request.view_timing = end - start return result return wrapper The ``view_callable`` argument to the factory will be the view callable found by Pyramid via view lookup. The ``request`` argument to the factory will be the current request. The ``exc`` argument to the factory will be an Exception object if the found view is an exception view; it will be ``None`` otherwise. View wrappers only last for the duration of a single request. You can add such a factory for every request by using the ``pyramid.events.NewRequest`` subscriber:: from pyramid.events import subscriber, NewRequest @subscriber(NewRequest) def newrequest(event): event.request.add_view_wrapper(wrapper_factory) If more than one view wrapper is registered during a single request, a 'later' view wrapper factory will be called with the result of its directly former view wrapper factory as its ``view_callable`` argument; this chain will be returned to Pyramid as a single view callable.
…have been looked up correctly when using Pyramid with ``zope.interface`` 3.6.4 and better. Closes #232.
…be passed as a kwarg to the Request constructor
``application/json``, this attribute will contain the JSON-decoded variant of the request body. If the request's ``content_type`` is not ``application/json``, this attribute will be ``None``.
attributes deprecated for ``pyramid.request.Request`` are accessed (like ``response_content_type``). This is for the benefit of folks running unit tests which use DummyRequest instead of a "real" request, so they know things are deprecated without necessarily needing a functional test suite.
(e.g. ``response_content_type``) now issues a deprecation warning at access time rather than at rendering time.
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.
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.
"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.