This article explains the new features in Pyramid version 1.0 as compared to its predecessor, repoze.bfg 1.3. It also documents backwards incompatibilities between the two versions and deprecations added to Pyramid 1.0, as well as software dependency changes and notable documentation additions.
The major feature additions in Pyramid 1.0 are:
The name of repoze.bfg has been changed to Pyramid. The project is also now a subproject of a new entity, “The Pylons Project”. The Pylons Project is the project name for a collection of web-framework-related technologies. Pyramid was the first package in the Pylons Project. Other packages to the collection have been added over time, such as support packages useful for Pylons 1 users as well as ex-Zope users. Pyramid is the successor to both repoze.bfg and Pylons version 1.
The Pyramid codebase is derived almost entirely from repoze.bfg with some changes made for the sake of Pylons 1 compatibility.
Pyramid is technically backwards incompatible with repoze.bfg, as it has a new package name, so older imports from the repoze.bfg module will fail if you do nothing to your existing repoze.bfg application. However, you won’t have to do much to use your existing BFG applications on Pyramid. There’s automation which will change most of your import statements and ZCML declarations. See http://docs.pylonsproject.org/projects/pyramid/current/tutorials/bfg/index.html for upgrade instructions.
Pylons 1 users will need to do more work to use Pyramid, as Pyramid shares no “DNA” with Pylons. It is hoped that over time documentation and upgrade code will be developed to help Pylons 1 users transition to Pyramid more easily.
repoze.bfg version 1.3 will be its last major release. Minor updates will be made for critical bug fixes. Pylons version 1 will continue to see maintenance releases, as well.
The Repoze project will continue to exist. Repoze will be able to regain its original focus: bringing Zope technologies to WSGI. The popularity of repoze.bfg as its own web framework hindered this goal.
We hope that people are attracted at first by the spirit of cooperation demonstrated by the Pylons Project and the merging of development communities. It takes humility to sacrifice a little sovereignty and work together. The opposite, forking or splintering of projects, is much more common in the open source world. We feel there is a limited amount of oxygen in the space of “top-tier” Python web frameworks and we don’t do the Python community a service by over-crowding. By merging the repoze.bfg and the philosophically-similar Pylons communities, both gain an expanded audience and a stronger chance of future success.
The bfg2pyramid conversion script performs a mostly automated conversion of an existing repoze.bfg application to Pyramid. The process is described in Converting a repoze.bfg Application to Pyramid.
The Pyramid concept previously known as “model” is now known as “resource”. As a result, the following API renames have been made. Backwards compatibility shims for the old names have been left in place in all cases:
pyramid.url.model_url ->
pyramid.url.resource_url
pyramid.traversal.find_model ->
pyramid.url.find_resource
pyramid.traversal.model_path ->
pyramid.traversal.resource_path
pyramid.traversal.model_path_tuple ->
pyramid.traversal.resource_path_tuple
pyramid.traversal.ModelGraphTraverser ->
pyramid.traversal.ResourceTreeTraverser
pyramid.config.Configurator.testing_models ->
pyramid.config.Configurator.testing_resources
pyramid.testing.registerModels ->
pyramid.testing.registerResources
pyramid.testing.DummyModel ->
pyramid.testing.DummyResource
All documentation which previously referred to “model” now refers to “resource”.
The starter scaffold now has a resources.py module instead of a models.py module.
Positional argument names of various APIs have been changed from model to resource.
The Pyramid concept previously known as “resource” is now known as “asset”. As a result, the following API changes were made. Backwards compatibility shims have been left in place as necessary:
pyramid.config.Configurator.absolute_resource_spec ->
pyramid.config.Configurator.absolute_asset_spec
pyramid.config.Configurator.override_resource ->
pyramid.config.Configurator.override_asset
The (non-API) module previously known as pyramid.resource is now known as pyramid.asset.
All docs that previously referred to “resource specification” now refer to “asset specification”.
The setting previously known as BFG_RELOAD_RESOURCES (envvar) or reload_resources (config file) is now known, respectively, as PYRAMID_RELOAD_ASSETS and reload_assets.
We’ve made Pyramid’s test suite pass on both Jython and PyPy. However, Chameleon doesn’t work on either, so you’ll need to use Mako or Jinja2 templates on these platforms.
Pyramid now has built-in sessioning support, documented in sessions_chapter. The sessioning implementation is pluggable. It also provides flash messaging and cross-site-scripting prevention features.
Using request.session now returns a (dictionary-like) session object if a session factory has been configured.
A new argument to the Configurator constructor exists: session_factory and a new method on the configurator exists: pyramid.config.Configurator.set_session_factory().
In addition to Chameleon templating, Pyramid now also provides built-in support for Mako templating. See Templating With Mako Templates for more information.
To support application extensibility, the Pyramid Configurator, by default, now detects configuration conflicts and allows you to include configuration imperatively from other packages or modules. It also, by default, performs configuration in two separate phases. This allows you to ignore relative configuration statement ordering in some circumstances. See 高度な設定 for more information.
The pyramid.config.Configurator.add_directive() allows framework extenders to add methods to the configurator, which allows extenders to avoid subclassing a Configurator just to add methods. See add_directive による Configurator へのメソッドの追加 for more info.
Surrounding application configuration with config.begin() and config.end() is no longer necessary. All scaffolds have been changed to no longer call these functions.
A new event type named pyramid.interfaces.IBeforeRender is now sent as an event before a renderer is invoked. Applications may now subscribe to the IBeforeRender event type in order to introspect the and modify the set of renderer globals before they are passed to a renderer. The event object iself has a dictionary-like interface that can be used for this purpose. For example:
from repoze.events import subscriber
from pyramid.interfaces import IRendererGlobalsEvent
@subscriber(IRendererGlobalsEvent)
def add_global(event):
event['mykey'] = 'foo'
A “view mapper” subsystem has been extracted, which allows framework extenders to control how view callables are constructed and called. This feature is not useful for “civilians”, only for extension writers. See ビューマッパーの変更 for more information.
The pyramid.testing.setUp() and pyramid.testing.tearDown() APIs have been undeprecated. They are now the canonical setup and teardown APIs for test configuration, replacing “direct” creation of a Configurator. This is a change designed to provide a facade that will protect against any future Configurator deprecations.
When a pyramid.exceptions.Forbidden error is raised, its status code now 403 Forbidden. It was previously 401 Unauthorized, for backwards compatibility purposes with repoze.bfg. This change will cause problems for users of Pyramid with repoze.who, which intercepts 401 Unauthorized by default, but allows 403 Forbidden to pass through. Those deployments will need to configure repoze.who to also react to 403 Forbidden. To do so, use a repoze.who challenge_decider that looks like this:
import zope.interface
from repoze.who.interfaces import IChallengeDecider
def challenge_decider(environ, status, headers):
return status.startswith('403') or status.startswith('401')
zope.interface.directlyProvides(challenge_decider, IChallengeDecider)
The paster bfgshell command is now known as paster pshell.
There is no longer an IDebugLogger object registered as a named utility with the name repoze.bfg.debug.
These deprecated APIs have been removed: pyramid.testing.registerViewPermission, pyramid.testing.registerRoutesMapper, pyramid.request.get_request, pyramid.security.Unauthorized, pyramid.view.view_execution_permitted, pyramid.view.NotFound
The Venusian “category” for all built-in Venusian decorators (e.g. subscriber and view_config/bfg_view) is now pyramid instead of bfg.
The pyramid.renderers.rendered_response function removed; use pyramid.renderers.render_to_response() instead.
Renderer factories now accept a renderer info object rather than an absolute resource specification or an absolute path. The object has the following attributes: name (the renderer= value), package (the ‘current package’ when the renderer configuration statement was found), type: the renderer type, registry: the current registry, and settings: the deployment settings dictionary. Third-party repoze.bfg renderer implementations that must be ported to Pyramid will need to account for this. This change was made primarily to support more flexible Mako template rendering.
The presence of the key repoze.bfg.message in the WSGI environment when an exception occurs is now deprecated. Instead, code which relies on this environ value should use the exception attribute of the request (e.g. request.exception[0]) to retrieve the message.
The values bfg_localizer and bfg_locale_name kept on the request during internationalization for caching purposes were never APIs. These however have changed to localizer and locale_name, respectively.
The default cookie_name value of the pyramid.authentication.AuthTktAuthenticationPolicy now defaults to auth_tkt (it used to default to repoze.bfg.auth_tkt).
The pyramid.testing.zcml_configure() API has been removed. It had been advertised as removed since repoze.bfg 1.2a1, but hadn’t actually been.
All environment variables which used to be prefixed with BFG_ are now prefixed with PYRAMID_ (e.g. BFG_DEBUG_NOTFOUND is now PYRAMID_DEBUG_NOTFOUND)
Since the pyramid.interfaces.IAuthenticationPolicy interface now specifies that a policy implementation must implement an unauthenticated_userid method, all third-party custom authentication policies now must implement this method. It, however, will only be called when the global function named pyramid.security.unauthenticated_userid() is invoked, so if you’re not invoking that, you will not notice any issues.
The configure_zcml setting within the deployment settings (within **settings passed to a Pyramid main function) has ceased to have any meaning.
The make_app function has been removed from the pyramid.router module. It continues life within the pyramid_zcml package. This leaves the pyramid.router module without any API functions.