This article explains the new features in Pyramid version 1.3 as compared to its predecessor, Pyramid 1.2. It also documents backwards incompatibilities between the two versions and deprecations added to Pyramid 1.3, as well as software dependency changes and notable documentation additions.

Major Feature Additions¶

The major feature additions in Pyramid 1.3 follow.

Python 3 Compatibility¶ Pyramid continues to run on Python 2, but Pyramid is now also Python 3 compatible. To use Pyramid under Python 3, Python 3.2 or better is required. Many Pyramid add-ons are already Python 3 compatible. For example, pyramid_debugtoolbar , pyramid_jinja2 , pyramid_exclog , pyramid_tm , pyramid_mailer , and pyramid_handlers are all Python 3-ready. But other add-ons are known to work only under Python 2. Also, some scaffolding dependencies (particularly ZODB) do not yet work under Python 3. Please be patient as we gain full ecosystem support for Python 3. You can see more details about ongoing porting efforts at https://github.com/Pylons/pyramid/wiki/Python-3-Porting . Python 3 compatibility required dropping some package dependencies and support for older Python versions and platforms. See the “Backwards Incompatibilities” section below for more information.

The paster Command Has Been Replaced¶ We’ve replaced the paster command with Pyramid-specific analogues. Why? The libraries that supported the paster command named Paste and PasteScript do not run under Python 3, and we were unwilling to port and maintain them ourselves. As a result, we’ve had to make some changes. Previously (in Pyramid 1.0, 1.1 and 1.2), you created a Pyramid application using paster create , like so: $ myvenv/bin/paster create -t pyramid_starter foo In 1.3, you’re now instead required to create an application using pcreate like so: $ myvenv/bin/pcreate -s starter foo pcreate is required to be used for internal Pyramid scaffolding; externally distributed scaffolding may allow for both pcreate and/or paster create . In previous Pyramid versions, you ran a Pyramid application like so: $ myvenv/bin/paster serve development.ini Instead, you now must use the pserve command in 1.3: $ myvenv/bin/pserve development.ini The ini configuration file format supported by Pyramid has not changed. As a result, Python 2-only users can install PasteScript manually and use paster serve instead if they like. However, using pserve will work under both Python 2 and Python 3. Analogues of paster pshell , paster pviews , paster request and paster ptweens also exist under the respective console script names pshell , pviews , prequest and ptweens .

paste.httpserver replaced by waitress in Scaffolds¶ Because the paste.httpserver server we used previously in scaffolds is not Python 3 compatible, we’ve made the default WSGI server used by Pyramid scaffolding the waitress server. The waitress server is both Python 2 and Python 3 compatible. Once you create a project from a scaffold, its development.ini and production.ini will have the following line: use = egg:waitress#main Instead of this (which was the default in older versions): use = egg:Paste#http Note paste.httpserver “helped” by converting header values that were Unicode into strings, which was a feature that subverted the WSGI specification. The waitress server, on the other hand implements the WSGI spec more fully. This specifically may affect you if you are modifying headers on your responses. The following error might be an indicator of this problem: AssertionError: Header values must be strings, please check the type of the header being returned. A common case would be returning Unicode headers instead of string headers.

Compatibility Helper Library¶ A new pyramid.compat module was added which provides Python 2/3 straddling support for Pyramid add-ons and development environments.

Introspection¶ A configuration introspection system was added; see Pyramid Configuration Introspection and Adding Configuration Introspection for more information on using the introspection system as a developer. The latest release of the pyramid debug toolbar (0.9.7+) provides an “Introspection” panel that exposes introspection information to a Pyramid application developer. New APIs were added to support introspection pyramid.registry.Introspectable , pyramid.config.Configurator.introspector , pyramid.config.Configurator.introspectable , pyramid.registry.Registry.introspector .

@view_defaults Decorator¶ If you use a class as a view, you can use the new pyramid.view.view_defaults class decorator on the class to provide defaults to the view configuration information used by every @view_config decorator that decorates a method of that class. For instance, if you’ve got a class that has methods that represent “REST actions”, all which are mapped to the same route, but different request methods, instead of this: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 from pyramid.view import view_config from pyramid.response import Response class RESTView ( object ): def __init__ ( self , request ): self . request = request @view_config ( route_name = 'rest' , request_method = 'GET' ) def get ( self ): return Response ( 'get' ) @view_config ( route_name = 'rest' , request_method = 'POST' ) def post ( self ): return Response ( 'post' ) @view_config ( route_name = 'rest' , request_method = 'DELETE' ) def delete ( self ): return Response ( 'delete' ) You can do this: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 from pyramid.view import view_defaults from pyramid.view import view_config from pyramid.response import Response @view_defaults ( route_name = 'rest' ) class RESTView ( object ): def __init__ ( self , request ): self . request = request @view_config ( request_method = 'GET' ) def get ( self ): return Response ( 'get' ) @view_config ( request_method = 'POST' ) def post ( self ): return Response ( 'post' ) @view_config ( request_method = 'DELETE' ) def delete ( self ): return Response ( 'delete' ) This also works for imperative view configurations that involve a class. See @view_defaults Class Decorator for more information.

Extending a Request without Subclassing¶ It is now possible to extend a pyramid.request.Request object with property descriptors without having to create a custom request factory. The new method pyramid.config.Configurator.set_request_property() provides an entry point for addons to register properties which will be added to each request. New properties may be reified, effectively caching the return value for the lifetime of the instance. Common use-cases for this would be to get a database connection for the request or identify the current user. The new method pyramid.request.Request.set_property() has been added, as well, but the configurator method should be preferred as it provides conflict detection and consistency in the lifetime of the properties.