Michael Merickel
2017-06-18 75c30dfe18b26ca04efae2acbe35052fa0d93ed6
docs/whatsnew-1.9.rst
@@ -35,6 +35,14 @@
- The threadlocals are now available inside any function invoked via :meth:`pyramid.config.Configurator.include`. This means the only config-time code that cannot rely on threadlocals is code executed from non-actions inside the main. This can be alleviated by invoking :meth:`pyramid.config.Configurator.begin` and :meth:`pyramid.config.Configurator.end` appropriately or using the new context manager feature of the configurator. See https://github.com/Pylons/pyramid/pull/2989
- The threadlocals are now available inside exception views invoked via :meth:`pyramid.request.Request.invoke_exception_view` even when the ``request`` argument is overridden. See https://github.com/Pylons/pyramid/pull/3060
- When unsupported predicates are supplied to :meth:`pyramid.config.Configurator.add_view`, :meth:`pyramid.config.Configurator.add_route` and :meth:`pyramid.config.Configurator.add_subscriber` a much more helpful error message is output with a guess as to which predicate was intended. See https://github.com/Pylons/pyramid/pull/3054
- Normalize the permission results to a proper class hierarchy. :class:`pyramid.security.ACLAllowed` is now a subclass of :class:`pyramid.security.Allowed` and :class:`pyramid.security.ACLDenied` is now a subclass of :class:`pyramid.security.Denied`. See https://github.com/Pylons/pyramid/pull/3084
- Add a ``quote_via`` argument to :func:`pyramid.encode.urlencode` to follow the stdlib's version and enable custom quoting functions. See https://github.com/Pylons/pyramid/pull/3088
Deprecations
------------
@@ -49,25 +57,11 @@
Backward Incompatibilities
--------------------------
- ``request.exception`` and ``request.exc_info`` will only be set if the
  response was generated by the EXCVIEW tween. This is to avoid any confusion
  where a response was generated elsewhere in the pipeline and not in
  direct relation to the original exception. If anyone upstream wants to
  catch and render responses for exceptions they should set
  ``request.exception`` and ``request.exc_info`` themselves to indicate
  the exception that was squashed when generating the response.
- ``request.exception`` and ``request.exc_info`` will only be set if the response was generated by the EXCVIEW tween. This is to avoid any confusion where a response was generated elsewhere in the pipeline and not in direct relation to the original exception. If anyone upstream wants to catch and render responses for exceptions they should set ``request.exception`` and ``request.exc_info`` themselves to indicate the exception that was squashed when generating the response.
  Similar behavior occurs with
  :meth:`pyramid.request.Request.invoke_exception_view` in which
  the exception properties are set to reflect the exception if a response
  is successfully generated by the method.
  Similar behavior occurs with :meth:`pyramid.request.Request.invoke_exception_view` in which the exception properties are set to reflect the exception if a response is successfully generated by the method.
  This is a very minor incompatibility. Most tweens right now would give
  priority to the raised exception and ignore ``request.exception``. This
  change just improves and clarifies that bookkeeping by trying to be
  more clear about the relationship between the response and its squashed
  exception. See https://github.com/Pylons/pyramid/pull/3029 and
  https://github.com/Pylons/pyramid/pull/3031
  This is a very minor incompatibility. Most tweens right now would give priority to the raised exception and ignore ``request.exception``. This change just improves and clarifies that bookkeeping by trying to be more clear about the relationship between the response and its squashed exception. See https://github.com/Pylons/pyramid/pull/3029 and https://github.com/Pylons/pyramid/pull/3031
Documentation Enhancements
--------------------------