| | |
|---|
| | | |
|---|
| | | This article explains the new features in :app:`Pyramid` version 1.9 as compared to its predecessor, :app:`Pyramid` 1.8. It also documents backwards incompatibilities between the two versions and deprecations added to :app:`Pyramid` 1.9, as well as software dependency changes and notable documentation additions. |
|---|
| | | |
|---|
| | | Bug Fix Releases |
|---|
| | | ---------------- |
|---|
| | | |
|---|
| | | Pyramid 1.9 was released on 2017-06-26. |
|---|
| | | |
|---|
| | | The following bug fix releases were made since then. Bug fix releases also include documentation improvements and other minor feature changes. |
|---|
| | | |
|---|
| | | - :ref:`changes_1.9.1` |
|---|
| | | |
|---|
| | | Major Feature Additions |
|---|
| | | ----------------------- |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | The first library to use this feature is `pyramid_retry <https://docs.pylonsproject.org/projects/pyramid-retry/en/latest/>`_. |
|---|
| | | |
|---|
| | | Pyramid's default :term:`execution policy` will attempt to handle and render uncaught exceptions. This is a subtle, but fundamental, change indicating that an :term:`exception view` may expect to be called outside of the default ``EXCVIEW`` tween. There are various predicates available to assist in defining valid exception views for various parts of the pipeline. For example, ``pyramid_tm`` defines the ``tm_active=True`` predicate which can be applied to exception views that require access to the default transaction. In general this means that exception views may be expected to cover more possible error conditions, including when exceptions occur from tweens that are placed **OVER** the ``EXCVIEW`` tween. If necessary, when provided a ``response`` object, you may inspect ``request.exception`` or ``request.exc_info`` to determine if the response was generated as the result of an exception. |
|---|
| | | See https://github.com/Pylons/pyramid/pull/2964 |
|---|
| | | |
|---|
| | | - CSRF support has been refactored out of sessions and into its own independent API in the :mod:`pyramid.csrf` module. It supports a pluggable :class:`pyramid.interfaces.ICSRFStoragePolicy` which can be used to define your own mechanism for generating and validating CSRF tokens. By default, Pyramid continues to use the :class:`pyramid.csrf.LegacySessionCSRFStoragePolicy` that uses the ``request.session.get_csrf_token`` and ``request.session.new_csrf_token`` APIs under the hood to preserve compatibility with older Pyramid applications. Two new policies are shipped as well, :class:`pyramid.csrf.SessionCSRFStoragePolicy` and :class:`pyramid.csrf.CookieCSRFStoragePolicy` which will store the CSRF tokens in the session and in a standalone cookie, respectively. The storage policy can be changed by using the new :meth:`pyramid.config.Configurator.set_csrf_storage_policy` config directive. |
|---|
