1.4a1 (2012-09-16)
|
==================
|
|
Bug Fixes
|
---------
|
|
- Forward port from 1.3 branch: When no authentication policy was configured,
|
a call to ``pyramid.security.effective_principals`` would unconditionally
|
return the empty list. This was incorrect, it should have unconditionally
|
returned ``[Everyone]``, and now does.
|
|
- Explicit url dispatch regexes can now contain colons.
|
https://github.com/Pylons/pyramid/issues/629
|
|
- On at least one 64-bit Ubuntu system under Python 3.2, using the
|
``view_config`` decorator caused a ``RuntimeError: dictionary changed size
|
during iteration`` exception. It no longer does. See
|
https://github.com/Pylons/pyramid/issues/635 for more information.
|
|
- In Mako Templates lookup, check if the uri is already adjusted and bring
|
it back to an asset spec. Normally occurs with inherited templates or
|
included components.
|
https://github.com/Pylons/pyramid/issues/606
|
https://github.com/Pylons/pyramid/issues/607
|
|
- In Mako Templates lookup, check for absolute uri (using mako directories)
|
when mixing up inheritance with asset specs.
|
https://github.com/Pylons/pyramid/issues/662
|
|
- HTTP Accept headers were not being normalized causing potentially
|
conflicting view registrations to go unnoticed. Two views that only
|
differ in the case ('text/html' vs. 'text/HTML') will now raise an error.
|
https://github.com/Pylons/pyramid/pull/620
|
|
- Forward-port from 1.3 branch: when registering multiple views with an
|
``accept`` predicate in a Pyramid application runing under Python 3, you
|
might have received a ``TypeError: unorderable types: function() <
|
function()`` exception.
|
|
Features
|
--------
|
|
- Configurator.add_directive now accepts arbitrary callables like partials or
|
objects implementing ``__call__`` which dont have ``__name__`` and
|
``__doc__`` attributes. See https://github.com/Pylons/pyramid/issues/621
|
and https://github.com/Pylons/pyramid/pull/647.
|
|
- Third-party custom view, route, and subscriber predicates can now be added
|
for use by view authors via
|
``pyramid.config.Configurator.add_view_predicate``,
|
``pyramid.config.Configurator.add_route_predicate`` and
|
``pyramid.config.Configurator.add_subscriber_predicate``. So, for example,
|
doing this::
|
|
config.add_view_predicate('abc', my.package.ABCPredicate)
|
|
Might allow a view author to do this in an application that configured that
|
predicate::
|
|
@view_config(abc=1)
|
|
Similar features exist for ``add_route``, and ``add_subscriber``. See
|
"Adding A Third Party View, Route, or Subscriber Predicate" in the Hooks
|
chapter for more information.
|
|
Note that changes made to support the above feature now means that only
|
actions registered using the same "order" can conflict with one another.
|
It used to be the case that actions registered at different orders could
|
potentially conflict, but to my knowledge nothing ever depended on this
|
behavior (it was a bit silly).
|
|
- Custom objects can be made easily JSON-serializable in Pyramid by defining
|
a ``__json__`` method on the object's class. This method should return
|
values natively serializable by ``json.dumps`` (such as ints, lists,
|
dictionaries, strings, and so forth).
|
|
- The JSON renderer now allows for the definition of custom type adapters to
|
convert unknown objects to JSON serializations.
|
|
- As of this release, the ``request_method`` predicate, when used, will also
|
imply that ``HEAD`` is implied when you use ``GET``. For example, using
|
``@view_config(request_method='GET')`` is equivalent to using
|
``@view_config(request_method=('GET', 'HEAD'))``. Using
|
``@view_config(request_method=('GET', 'POST')`` is equivalent to using
|
``@view_config(request_method=('GET', 'HEAD', 'POST')``. This is because
|
HEAD is a variant of GET that omits the body, and WebOb has special support
|
to return an empty body when a HEAD is used.
|
|
- ``config.add_request_method`` has been introduced to support extending
|
request objects with arbitrary callables. This method expands on the
|
previous ``config.set_request_property`` by supporting methods as well as
|
properties. This method now causes less code to be executed at
|
request construction time than ``config.set_request_property`` in
|
version 1.3.
|
|
- Don't add a ``?`` to URLs generated by ``request.resource_url`` if the
|
``query`` argument is provided but empty.
|
|
- Don't add a ``?`` to URLs generated by ``request.route_url`` if the
|
``_query`` argument is provided but empty.
|
|
- The static view machinery now raises (rather than returns) ``HTTPNotFound``
|
and ``HTTPMovedPermanently`` exceptions, so these can be caught by the
|
NotFound view (and other exception views).
|
|
- The Mako renderer now supports a def name in an asset spec. When the def
|
name is present in the asset spec, the system will render the template def
|
within the template and will return the result. An example asset spec is
|
``package:path/to/template#defname.mako``. This will render the def named
|
``defname`` inside the ``template.mako`` template instead of rendering the
|
entire template. The old way of returning a tuple in the form
|
``('defname', {})`` from the view is supported for backward compatibility,
|
|
- The Chameleon ZPT renderer now accepts a macro name in an asset spec. When
|
the macro name is present in the asset spec, the system will render the
|
macro listed as a ``define-macro`` and return the result instead of
|
rendering the entire template. An example asset spec:
|
``package:path/to/template#macroname.pt``. This will render the macro
|
defined as ``macroname`` within the ``template.pt`` template instead of the
|
entire templae.
|
|
- When there is a predicate mismatch exception (seen when no view matches for
|
a given request due to predicates not working), the exception now contains
|
a textual description of the predicate which didn't match.
|
|
- An ``add_permission`` directive method was added to the Configurator. This
|
directive registers a free-standing permission introspectable into the
|
Pyramid introspection system. Frameworks built atop Pyramid can thus use
|
the the ``permissions`` introspectable category data to build a
|
comprehensive list of permissions supported by a running system. Before
|
this method was added, permissions were already registered in this
|
introspectable category as a side effect of naming them in an ``add_view``
|
call, this method just makes it possible to arrange for a permission to be
|
put into the ``permissions`` introspectable category without naming it
|
along with an associated view. Here's an example of usage of
|
``add_permission``::
|
|
config = Configurator()
|
config.add_permission('view')
|
|
- The ``UnencryptedCookieSessionFactoryConfig`` now accepts
|
``signed_serialize`` and ``signed_deserialize`` hooks which may be used
|
to influence how the sessions are marshalled (by default this is done
|
with HMAC+pickle).
|
|
- ``pyramid.testing.DummyRequest`` now supports methods supplied by the
|
``pyramid.util.InstancePropertyMixin`` class such as ``set_property``.
|
|
- Request properties and methods added via ``config.set_request_property`` or
|
``config.add_request_method`` are now available to tweens.
|
|
- Request properties and methods added via ``config.set_request_property`` or
|
``config.add_request_method`` are now available in the request object
|
returned from ``pyramid.paster.bootstrap``.
|
|
- ``request.context`` of environment request during ``bootstrap`` is now the
|
root object if a context isn't already set on a provided request.
|
|
- The ``pyramid.decorator.reify`` function is now an API, and was added to
|
the API documentation.
|
|
- Added the ``pyramid.testing.testConfig`` context manager, which can be used
|
to generate a configurator in a test, e.g. ``with testing.testConfig(...):``.
|
|
- Users can now invoke a subrequest from within view code using a new
|
``request.invoke_subrequest`` API.
|
|
Deprecations
|
------------
|
|
- The ``pyramid.config.Configurator.set_request_property`` has been
|
documentation-deprecated. The method remains usable but the more
|
featureful ``pyramid.config.Configurator.add_request_method`` should be
|
used in its place (it has all of the same capabilities but can also extend
|
the request object with methods).
|
|
Backwards Incompatibilities
|
---------------------------
|
|
- The Pyramid router no longer adds the values ``bfg.routes.route`` or
|
``bfg.routes.matchdict`` to the request's WSGI environment dictionary.
|
These values were docs-deprecated in ``repoze.bfg`` 1.0 (effectively seven
|
minor releases ago). If your code depended on these values, use
|
request.matched_route and request.matchdict instead.
|
|
- It is no longer possible to pass an environ dictionary directly to
|
``pyramid.traversal.ResourceTreeTraverser.__call__`` (aka
|
``ModelGraphTraverser.__call__``). Instead, you must pass a request
|
object. Passing an environment instead of a request has generated a
|
deprecation warning since Pyramid 1.1.
|
|
- Pyramid will no longer work properly if you use the
|
``webob.request.LegacyRequest`` as a request factory. Instances of the
|
LegacyRequest class have a ``request.path_info`` which return a string.
|
This Pyramid release assumes that ``request.path_info`` will
|
unconditionally be Unicode.
|
|
- The functions from ``pyramid.chameleon_zpt`` and ``pyramid.chameleon_text``
|
named ``get_renderer``, ``get_template``, ``render_template``, and
|
``render_template_to_response`` have been removed. These have issued a
|
deprecation warning upon import since Pyramid 1.0. Use
|
``pyramid.renderers.get_renderer()``,
|
``pyramid.renderers.get_renderer().implementation()``,
|
``pyramid.renderers.render()`` or ``pyramid.renderers.render_to_response``
|
respectively instead of these functions.
|
|
- The ``pyramid.configuration`` module was removed. It had been deprecated
|
since Pyramid 1.0 and printed a deprecation warning upon its use. Use
|
``pyramid.config`` instead.
|
|
- The ``pyramid.paster.PyramidTemplate`` API was removed. It had been
|
deprecated since Pyramid 1.1 and issued a warning on import. If your code
|
depended on this, adjust your code to import
|
``pyramid.scaffolds.PyramidTemplate`` instead.
|
|
- The ``pyramid.settings.get_settings()`` API was removed. It had been
|
printing a deprecation warning since Pyramid 1.0. If your code depended on
|
this API, use ``pyramid.threadlocal.get_current_registry().settings``
|
instead or use the ``settings`` attribute of the registry available from
|
the request (``request.registry.settings``).
|
|
- These APIs from the ``pyramid.testing`` module were removed. They have
|
been printing deprecation warnings since Pyramid 1.0:
|
|
* ``registerDummySecurityPolicy``, use
|
``pyramid.config.Configurator.testing_securitypolicy`` instead.
|
|
* ``registerResources`` (aka ``registerModels``, use
|
``pyramid.config.Configurator.testing_resources`` instead.
|
|
* ``registerEventListener``, use
|
``pyramid.config.Configurator.testing_add_subscriber`` instead.
|
|
* ``registerTemplateRenderer`` (aka `registerDummyRenderer``), use
|
``pyramid.config.Configurator.testing_add_template`` instead.
|
|
* ``registerView``, use ``pyramid.config.Configurator.add_view`` instead.
|
|
* ``registerUtility``, use
|
``pyramid.config.Configurator.registry.registerUtility`` instead.
|
|
* ``registerAdapter``, use
|
``pyramid.config.Configurator.registry.registerAdapter`` instead.
|
|
* ``registerSubscriber``, use
|
``pyramid.config.Configurator.add_subscriber`` instead.
|
|
* ``registerRoute``, use
|
``pyramid.config.Configurator.add_route`` instead.
|
|
* ``registerSettings``, use
|
``pyramid.config.Configurator.add_settings`` instead.
|
|
- In Pyramid 1.3 and previous, the ``__call__`` method of a Response object
|
was invoked before any finished callbacks were executed. As of this
|
release, the ``__call__`` method of a Response object is invoked *after*
|
finished callbacks are executed. This is in support of the
|
``request.invoke_subrequest`` feature.
|
|
Documentation
|
-------------
|
|
- Added an "Upgrading Pyramid" chapter to the narrative documentation. It
|
describes how to cope with deprecations and removals of Pyramid APIs and
|
how to show Pyramid-generated deprecation warnings while running tests and
|
while running a server.
|
|
- Added a "Invoking a Subrequest" chapter to the documentation. It describes
|
how to use the new ``request.invoke_subrequest`` API.
|
|
Dependencies
|
------------
|
|
- Pyramid now requires WebOb 1.2b3+ (the prior Pyramid release only relied on
|
1.2dev+). This is to ensure that we obtain a version of WebOb that returns
|
``request.path_info`` as text.
|
