diff options
Diffstat (limited to 'CHANGES.txt')
| -rw-r--r-- | CHANGES.txt | 1101 |
1 files changed, 416 insertions, 685 deletions
diff --git a/CHANGES.txt b/CHANGES.txt index 08e498b7a..051328a02 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,9 +1,312 @@ -next release -============ +Unreleased +========== + +Bug Fixes +--------- + +- Fix the ``pcreate`` script so that when the target directory name ends with a + slash it does not produce a non-working project directory structure. + Previously saying ``pcreate -s starter /foo/bar/`` produced different output + than saying ``pcreate -s starter /foo/bar``. The former did not work + properly. + +- Fix the ``principals_allowed_by_permission`` method of + ``ACLAuthorizationPolicy`` so it anticipates a callable ``__acl__`` + on resources. Previously it did not try to call the ``__acl__`` + if it was callable. + +- The ``pviews`` script did not work when a url required custom request + methods in order to perform traversal. Custom methods and descriptors added + via ``pyramid.config.Configurator.add_request_method`` will now be present, + allowing traversal to continue. + See https://github.com/Pylons/pyramid/issues/1104 + +Documentation +------------- + +- Added a "Quick Tutorial" to go with the Quick Tour + +- Removed mention of ``pyramid_beaker`` from docs. Beaker is no longer + maintained. Point people at ``pyramid_redis_sessions`` instead. + +Backwards Incompatibilities +--------------------------- + +- The key/values in the ``_query`` parameter of ``request.route_url`` and the + ``query`` parameter of ``request.resource_url`` (and their variants), used + to encode a value of ``None`` as the string ``'None'``, leaving the resulting + query string to be ``a=b&key=None``. The value is now dropped in this + situation, leaving a query string of ``a=b&key=``. + See https://github.com/Pylons/pyramid/issues/1119 + +1.5a2 (2013-09-22) +================== + +Features +-------- + +- Users can now provide dotted Python names to as the ``factory`` argument + the Configurator methods named ``add_{view,route,subscriber}_predicate`` + (instead of passing the predicate factory directly, you can pass a + dotted name which refers to the factory). + +Bug Fixes +--------- + +- Fix an exception in ``pyramid.path.package_name`` when resolving the package + name for namespace packages that had no ``__file__`` attribute. + +Backwards Incompatibilities +--------------------------- + +- Pyramid no longer depends on or configures the Mako and Chameleon templating + system renderers by default. Disincluding these templating systems by + default means that the Pyramid core has fewer dependencies and can run on + future platforms without immediate concern for the compatibility of its + templating add-ons. It also makes maintenance slightly more effective, as + different people can maintain the templating system add-ons that they + understand and care about without needing commit access to the Pyramid core, + and it allows users who just don't want to see any packages they don't use + come along for the ride when they install Pyramid. + + This means that upon upgrading to Pyramid 1.5a2+, projects that use either + of these templating systems will see a traceback that ends something like + this when their application attempts to render a Chameleon or Mako template:: + + ValueError: No such renderer factory .pt + + Or:: + + ValueError: No such renderer factory .mako + + Or:: + + ValueError: No such renderer factory .mak + + Support for Mako templating has been moved into an add-on package named + ``pyramid_mako``, and support for Chameleon templating has been moved into + an add-on package named ``pyramid_chameleon``. These packages are drop-in + replacements for the old built-in support for these templating langauges. + All you have to do is install them and make them active in your configuration + to register renderer factories for ``.pt`` and/or ``.mako`` (or ``.mak``) to + make your application work again. + + To re-add support for Chameleon and/or Mako template renderers into your + existing projects, follow the below steps. + + If you depend on Mako templates: + + * Make sure the ``pyramid_mako`` package is installed. One way to do this + is by adding ``pyramid_mako`` to the ``install_requires`` section of your + package's ``setup.py`` file and afterwards rerunning ``setup.py develop``:: + + setup( + #... + install_requires=[ + 'pyramid_mako', # new dependency + 'pyramid', + #... + ], + ) + + * Within the portion of your application which instantiates a Pyramid + ``pyramid.config.Configurator`` (often the ``main()`` function in + your project's ``__init__.py`` file), tell Pyramid to include the + ``pyramid_mako`` includeme:: + + config = Configurator(.....) + config.include('pyramid_mako') + + If you depend on Chameleon templates: + + * Make sure the ``pyramid_chameleon`` package is installed. One way to do + this is by adding ``pyramid_chameleon`` to the ``install_requires`` section + of your package's ``setup.py`` file and afterwards rerunning + ``setup.py develop``:: + + setup( + #... + install_requires=[ + 'pyramid_chameleon', # new dependency + 'pyramid', + #... + ], + ) + + * Within the portion of your application which instantiates a Pyramid + ``~pyramid.config.Configurator`` (often the ``main()`` function in + your project's ``__init__.py`` file), tell Pyramid to include the + ``pyramid_chameleon`` includeme:: + + config = Configurator(.....) + config.include('pyramid_chameleon') + + Note that it's also fine to install these packages into *older* Pyramids for + forward compatibility purposes. Even if you don't upgrade to Pyramid 1.5 + immediately, performing the above steps in a Pyramid 1.4 installation is + perfectly fine, won't cause any difference, and will give you forward + compatibility when you eventually do upgrade to Pyramid 1.5. + + With the removal of Mako and Chameleon support from the core, some + unit tests that use the ``pyramid.renderers.render*`` methods may begin to + fail. If any of your unit tests are invoking either + ``pyramid.renderers.render()`` or ``pyramid.renderers.render_to_response()`` + with either Mako or Chameleon templates then the + ``pyramid.config.Configurator`` instance in effect during + the unit test should be also be updated to include the addons, as shown + above. For example:: + + class ATest(unittest.TestCase): + def setUp(self): + self.config = pyramid.testing.setUp() + self.config.include('pyramid_mako') + + def test_it(self): + result = pyramid.renderers.render('mypkg:templates/home.mako', {}) + + Or:: + + class ATest(unittest.TestCase): + def setUp(self): + self.config = pyramid.testing.setUp() + self.config.include('pyramid_chameleon') + + def test_it(self): + result = pyramid.renderers.render('mypkg:templates/home.pt', {}) + +- If you're using the Pyramid debug toolbar, when you upgrade Pyramid to + 1.5a2+, you'll also need to upgrade the ``pyramid_debugtoolbar`` package to + at least version 1.0.8, as older toolbar versions are not compatible with + Pyramid 1.5a2+ due to the removal of Mako support from the core. It's + fine to use this newer version of the toolbar code with older Pyramids too. + +- Removed the ``request.response_*`` varying attributes. These attributes + have been deprecated since Pyramid 1.1, and as per the deprecation policy, + have now been removed. + +- ``request.response`` will no longer be mutated when using the + ``pyramid.renderers.render()`` API. Almost all renderers mutate the + ``request.response`` response object (for example, the JSON renderer sets + ``request.response.content_type`` to ``application/json``), but this is + only necessary when the renderer is generating a response; it was a bug + when it was done as a side effect of calling ``pyramid.renderers.render()``. + +- Removed the ``bfg2pyramid`` fixer script. + +- The ``pyramid.events.NewResponse`` event is now sent **after** response + callbacks are executed. It previously executed before response callbacks + were executed. Rationale: it's more useful to be able to inspect the response + after response callbacks have done their jobs instead of before. + +- Removed the class named ``pyramid.view.static`` that had been deprecated + since Pyramid 1.1. Instead use ``pyramid.static.static_view`` with + ``use_subpath=True`` argument. + +- Removed the ``pyramid.view.is_response`` function that had been deprecated + since Pyramid 1.1. Use the ``pyramid.request.Request.is_response`` method + instead. + +- Removed the ability to pass the following arguments to + ``pyramid.config.Configurator.add_route``: ``view``, ``view_context``. + ``view_for``, ``view_permission``, ``view_renderer``, and ``view_attr``. + Using these arguments had been deprecated since Pyramid 1.1. Instead of + passing view-related arguments to ``add_route``, use a separate call to + ``pyramid.config.Configurator.add_view`` to associate a view with a route + using its ``route_name`` argument. Note that this impacts the + ``pyramid.config.Configurator.add_static_view`` function too, because it + delegates to ``add_route``. + +- Removed the ability to influence and query a ``pyramid.request.Request`` + object as if it were a dictionary. Previously it was possible to use methods + like ``__getitem__``, ``get``, ``items``, and other dictlike methods to + access values in the WSGI environment. This behavior had been deprecated + since Pyramid 1.1. Use methods of ``request.environ`` (a real dictionary) + instead. + +- Removed ancient backwards compatibily hack in + ``pyramid.traversal.DefaultRootFactory`` which populated the ``__dict__`` of + the factory with the matchdict values for compatibility with BFG 0.9. + +- The ``renderer_globals_factory`` argument to the + ``pyramid.config.Configurator` constructor and its ``setup_registry`` method + has been removed. The ``set_renderer_globals_factory`` method of + ``pyramid.config.Configurator`` has also been removed. The (internal) + ``pyramid.interfaces.IRendererGlobals`` interface was also removed. These + arguments, methods and interfaces had been deprecated since 1.1. Use a + ``BeforeRender`` event subscriber as documented in the "Hooks" chapter of the + Pyramid narrative documentation instead of providing renderer globals values + to the configurator. + +Deprecations +------------ + +- The ``pyramid.config.Configurator.set_request_property`` method now issues + a deprecation warning when used. It had been docs-deprecated in 1.4 + but did not issue a deprecation warning when used. + +1.5a1 (2013-08-30) +================== Features -------- +- A new http exception subclass named ``pyramid.httpexceptions.HTTPSuccessful`` + was added. You can use this class as the ``context`` of an exception + view to catch all 200-series "exceptions" (e.g. "raise HTTPOk"). This + also allows you to catch *only* the ``HTTPOk`` exception itself; previously + this was impossible because a number of other exceptions + (such as ``HTTPNoContent``) inherited from ``HTTPOk``, but now they do not. + +- You can now generate "hybrid" urldispatch/traversal URLs more easily + by using the new ``route_name``, ``route_kw`` and ``route_remainder_name`` + arguments to ``request.resource_url`` and ``request.resource_path``. See + the new section of the "Combining Traversal and URL Dispatch" documentation + chapter entitled "Hybrid URL Generation". + +- It is now possible to escape double braces in Pyramid scaffolds (unescaped, + these represent replacement values). You can use ``\{\{a\}\}`` to + represent a "bare" ``{{a}}``. See + https://github.com/Pylons/pyramid/pull/862 + +- Add ``localizer`` and ``locale_name`` properties (reified) to the request. + See https://github.com/Pylons/pyramid/issues/508. Note that the + ``pyramid.i18n.get_localizer`` and ``pyramid.i18n.get_locale_name`` functions + now simply look up these properties on the request. + +- Add ``pdistreport`` script, which prints the Python version in use, the + Pyramid version in use, and the version number and location of all Python + distributions currently installed. + +- Add the ability to invert the result of any view, route, or subscriber + predicate using the ``not_`` class. For example:: + + from pyramid.config import not_ + + @view_config(route_name='myroute', request_method=not_('POST')) + def myview(request): ... + + The above example will ensure that the view is called if the request method + is not POST (at least if no other view is more specific). + + The ``pyramid.config.not_`` class can be used against any value that is + a predicate value passed in any of these contexts: + + - ``pyramid.config.Configurator.add_view`` + + - ``pyramid.config.Configurator.add_route`` + + - ``pyramid.config.Configurator.add_subscriber`` + + - ``pyramid.view.view_config`` + + - ``pyramid.events.subscriber`` + +- ``scripts/prequest.py``: add support for submitting ``PUT`` and ``PATCH`` + requests. See https://github.com/Pylons/pyramid/pull/1033. add support for + submitting ``OPTIONS`` and ``PROPFIND`` requests, and allow users to specify + basic authentication credentials in the request via a ``--login`` argument to + the script. See https://github.com/Pylons/pyramid/pull/1039. + - ``ACLAuthorizationPolicy`` supports ``__acl__`` as a callable. This removes the ambiguity between the potential ``AttributeError`` that would be raised on the ``context`` when the property was not defined and the @@ -15,6 +318,19 @@ Features ``pyramid.config.Configurator.add_static_view``. This allows externally-hosted static URLs to be generated based on the current protocol. +- The ``AuthTktAuthenticationPolicy`` has two new options to configure its + domain usage: + + * ``parent_domain``: if set the authentication cookie is set on + the parent domain. This is useful if you have multiple sites sharing the + same domain. + * ``domain``: if provided the cookie is always set for this domain, bypassing + all usual logic. + + See https://github.com/Pylons/pyramid/pull/1028, + https://github.com/Pylons/pyramid/pull/1072 and + https://github.com/Pylons/pyramid/pull/1078. + - The ``AuthTktAuthenticationPolicy`` now supports IPv6 addresses when using the ``include_ip=True`` option. This is possibly incompatible with alternative ``auth_tkt`` implementations, as the specification does not @@ -29,8 +345,10 @@ Features ``initialize_myapp_db etc/development.ini a=1 b=2``. See https://github.com/Pylons/pyramid/pull/911 -Bug Fixes ---------- +- The ``request.session.check_csrf_token()`` method and the ``check_csrf`` view + predicate now take into account the value of the HTTP header named + ``X-CSRF-Token`` (as well as the ``csrf_token`` form parameter, which they + always did). The header is tried when the form parameter does not exist. - View lookup will now search for valid views based on the inheritance hierarchy of the context. It tries to find views based on the most @@ -41,8 +359,6 @@ Bug Fixes raised. Now predicate mismatches don't hide valid views registered on super-types. Here's an example that now works:: - .. code-block:: python - class IResource(Interface): ... @@ -62,7 +378,7 @@ Bug Fixes ... - @implementor(IResource) + @implementer(IResource) class MyResource: ... @@ -77,700 +393,115 @@ Bug Fixes predicate mismatch error when trying to use GET or DELETE methods. Now the views are found and no predicate mismatch is raised. + See https://github.com/Pylons/pyramid/pull/786 and + https://github.com/Pylons/pyramid/pull/1004 and + https://github.com/Pylons/pyramid/pull/1046 -- Spaces and dots may now be in mako renderer template paths. This was - broken when support for the new makodef syntax was added in 1.4a1. - See https://github.com/Pylons/pyramid/issues/950 - -- ``pyramid.debug_authorization=true`` will now correctly print out - ``Allowed`` for views registered with ``NO_PERMISSION_REQUIRED`` instead - of invoking the ``permits`` method of the authorization policy. - See https://github.com/Pylons/pyramid/issues/954 - -1.4 (2012-12-18) -================ - -Docs ----- - -- Fix functional tests in the ZODB tutorial - -1.4b3 (2012-12-10) -================== - -- Packaging release only, no code changes. 1.4b2 was a brownbag release due to - missing directories in the tarball. - -1.4b2 (2012-12-10) -================== - -Docs ----- - -- Scaffolding is now PEP-8 compliant (at least for a brief shining moment). - -- Tutorial improvements. - -Backwards Incompatibilities ---------------------------- - -- Modified the ``_depth`` argument to ``pyramid.view.view_config`` to accept - a value relative to the invocation of ``view_config`` itself. Thus, when it - was previously expecting a value of ``1`` or greater, to reflect that - the caller of ``view_config`` is 1 stack frame away from ``venusian.attach``, - this implementation detail is now hidden. - -- Modified the ``_backframes`` argument to ``pyramid.util.action_method`` in a - similar way to the changes described to ``_depth`` above. This argument - remains undocumented, but might be used in the wild by some insane person. - -1.4b1 (2012-11-21) -================== - -Features --------- - -- Small microspeed enhancement which anticipates that a - ``pyramid.response.Response`` object is likely to be returned from a view. - Some code is shortcut if the class of the object returned by a view is this - class. A similar microoptimization was done to - ``pyramid.request.Request.is_response``. - -- Make it possible to use variable arguments on ``p*`` commands (``pserve``, - ``pshell``, ``pviews``, etc) in the form ``a=1 b=2`` so you can fill in - values in parameterized ``.ini`` file, e.g. ``pshell etc/development.ini - http_port=8080``. See https://github.com/Pylons/pyramid/pull/714 - -- A somewhat advanced and obscure feature of Pyramid event handlers is their - ability to handle "multi-interface" notifications. These notifications have - traditionally presented multiple objects to the subscriber callable. For - instance, if an event was sent by code like this:: - - registry.notify(event, context) - - In the past, in order to catch such an event, you were obligated to write and - register an event subscriber that mentioned both the event and the context in - its argument list:: - - @subscriber([SomeEvent, SomeContextType]) - def asubscriber(event, context): - pass - - In many subscriber callables registered this way, it was common for the logic - in the subscriber callable to completely ignore the second and following - arguments (e.g. ``context`` in the above example might be ignored), because - they usually existed as attributes of the event anyway. You could usually - get the same value by doing ``event.context`` or similar. - - The fact that you needed to put an extra argument which you usually ignored - in the subscriber callable body was only a minor annoyance until we added - "subscriber predicates", used to narrow the set of circumstances under which - a subscriber will be executed, in a prior 1.4 alpha release. Once those were - added, the annoyance was escalated, because subscriber predicates needed to - accept the same argument list and arity as the subscriber callables that they - were configured against. So, for example, if you had these two subscriber - registrations in your code:: - - @subscriber([SomeEvent, SomeContextType]) - def asubscriber(event, context): - pass - - @subscriber(SomeOtherEvent) - def asubscriber(event): - pass - - And you wanted to use a subscriber predicate:: - - @subscriber([SomeEvent, SomeContextType], mypredicate=True) - def asubscriber1(event, context): - pass - - @subscriber(SomeOtherEvent, mypredicate=True) - def asubscriber2(event): - pass - - If an existing ``mypredicate`` subscriber predicate had been written in such - a way that it accepted only one argument in its ``__call__``, you could not - use it against a subscription which named more than one interface in its - subscriber interface list. Similarly, if you had written a subscriber - predicate that accepted two arguments, you couldn't use it against a - registration that named only a single interface type. - - For example, if you created this predicate:: - - class MyPredicate(object): - # portions elided... - def __call__(self, event): - return self.val == event.context.foo - - It would not work against a multi-interface-registered subscription, so in - the above example, when you attempted to use it against ``asubscriber1``, it - would fail at runtime with a TypeError, claiming something was attempting to - call it with too many arguments. - - To hack around this limitation, you were obligated to design the - ``mypredicate`` predicate to expect to receive in its ``__call__`` either a - single ``event`` argument (a SomeOtherEvent object) *or* a pair of arguments - (a SomeEvent object and a SomeContextType object), presumably by doing - something like this:: - - class MyPredicate(object): - # portions elided... - def __call__(self, event, context=None): - return self.val == event.context.foo - - This was confusing and bad. - - In order to allow people to ignore unused arguments to subscriber callables - and to normalize the relationship between event subscribers and subscriber - predicates, we now allow both subscribers and subscriber predicates to accept - only a single ``event`` argument even if they've been subscribed for - notifications that involve multiple interfaces. Subscribers and subscriber - predicates that accept only one argument will receive the first object passed - to ``notify``; this is typically (but not always) the event object. The - other objects involved in the subscription lookup will be discarded. You can - now write an event subscriber that accepts only ``event`` even if it - subscribes to multiple interfaces:: - - @subscriber([SomeEvent, SomeContextType]) - def asubscriber(event): - # this will work! - - This prevents you from needing to match the subscriber callable parameters to - the subscription type unnecessarily, especially when you don't make use of - any argument in your subscribers except for the event object itself. - - Note, however, that if the event object is not the first - object in the call to ``notify``, you'll run into trouble. For example, if - notify is called with the context argument first:: - - registry.notify(context, event) - - You won't be able to take advantage of the event-only feature. It will - "work", but the object received by your event handler won't be the event - object, it will be the context object, which won't be very useful:: - - @subscriber([SomeContextType, SomeEvent]) - def asubscriber(event): - # bzzt! you'll be getting the context here as ``event``, and it'll - # be useless - - Existing multiple-argument subscribers continue to work without issue, so you - should continue use those if your system notifies using multiple interfaces - and the first interface is not the event interface. For example:: - - @subscriber([SomeContextType, SomeEvent]) - def asubscriber(context, event): - # this will still work! - - The event-only feature makes it possible to use a subscriber predicate that - accepts only a request argument within both multiple-interface subscriber - registrations and single-interface subscriber registrations. You needn't - make slightly different variations of predicates depending on the - subscription type arguments. Instead, just write all your subscriber - predicates so they only accept ``event`` in their ``__call__`` and they'll be - useful across all registrations for subscriptions that use an event as their - first argument, even ones which accept more than just ``event``. - - However, the same caveat applies to predicates as to subscriber callables: if - you're subscribing to a multi-interface event, and the first interface is not - the event interface, the predicate won't work properly. In such a case, - you'll need to match the predicate ``__call__`` argument ordering and - composition to the ordering of the interfaces. For example, if the - registration for the subscription uses ``[SomeContext, SomeEvent]``, you'll - need to reflect that in the ordering of the parameters of the predicate's - ``__call__`` method:: - - def __call__(self, context, event): - return event.request.path.startswith(self.val) - - tl;dr: 1) When using multi-interface subscriptions, always use the event type - as the first subscription registration argument and 2) When 1 is true, use - only ``event`` in your subscriber and subscriber predicate parameter lists, - no matter how many interfaces the subscriber is notified with. This - combination will result in the maximum amount of reusability of subscriber - predicates and the least amount of thought on your part. Drink responsibly. - -Bug Fixes ---------- - -- A failure when trying to locate the attribute ``__text__`` on route and view - predicates existed when the ``debug_routematch`` setting was true or when the - ``pviews`` command was used. See https://github.com/Pylons/pyramid/pull/727 - -Documentation -------------- - -- Sync up tutorial source files with the files that are rendered by the - scaffold that each uses. +- The ``pserve`` command now takes a ``-v`` (or ``--verbose``) flag and a + ``-q`` (or ``--quiet``) flag. Output from running ``pserve`` can be + controlled using these flags. ``-v`` can be specified multiple times to + increase verbosity. ``-q`` sets verbosity to ``0`` unconditionally. The + default verbosity level is ``1``. -1.4a4 (2012-11-14) -================== - -Features --------- - -- ``pyramid.authentication.AuthTktAuthenticationPolicy`` has been updated to - support newer hashing algorithms such as ``sha512``. Existing applications - should consider updating if possible for improved security over the default - md5 hashing. - -- Added an ``effective_principals`` route and view predicate. - -- Do not allow the userid returned from the ``authenticated_userid`` or the - userid that is one of the list of principals returned by - ``effective_principals`` to be either of the strings ``system.Everyone`` or - ``system.Authenticated`` when any of the built-in authorization policies that - live in ``pyramid.authentication`` are in use. These two strings are - reserved for internal usage by Pyramid and they will not be accepted as valid - userids. - -- Slightly better debug logging from - ``pyramid.authentication.RepozeWho1AuthenticationPolicy``. - -- ``pyramid.security.view_execution_permitted`` used to return ``True`` if no - view could be found. It now raises a ``TypeError`` exception in that case, as - it doesn't make sense to assert that a nonexistent view is - execution-permitted. See https://github.com/Pylons/pyramid/issues/299. - -- Allow a ``_depth`` argument to ``pyramid.view.view_config``, which will - permit limited composition reuse of the decorator by other software that - wants to provide custom decorators that are much like view_config. - -- Allow an iterable of decorators to be passed to - ``pyramid.config.Configurator.add_view``. This allows views to be wrapped - by more than one decorator without requiring combining the decorators - yourself. - -Bug Fixes ---------- - -- In the past if a renderer returned ``None``, the body of the resulting - response would be set explicitly to the empty string. Instead, now, the body - is left unchanged, which allows the renderer to set a body itself by using - e.g. ``request.response.body = b'foo'``. The body set by the renderer will - be unmolested on the way out. See - https://github.com/Pylons/pyramid/issues/709 - -- In uncommon cases, the ``pyramid_excview_tween_factory`` might have - inadvertently raised a ``KeyError`` looking for ``request_iface`` as an - attribute of the request. It no longer fails in this case. See - https://github.com/Pylons/pyramid/issues/700 - -- Be more tolerant of potential error conditions in ``match_param`` and - ``physical_path`` predicate implementations; instead of raising an exception, - return False. - -- ``pyramid.view.render_view`` was not functioning properly under Python 3.x - due to a byte/unicode discrepancy. See - https://github.com/Pylons/pyramid/issues/721 - -Deprecations ------------- - -- ``pyramid.authentication.AuthTktAuthenticationPolicy`` will emit a warning if - an application is using the policy without explicitly passing a ``hashalg`` - argument. This is because the default is "md5" which is considered - theoretically subject to collision attacks. If you really want "md5" then you - must specify it explicitly to get rid of the warning. - -Documentation -------------- - -- All of the tutorials that use - ``pyramid.authentication.AuthTktAuthenticationPolicy`` now explicitly pass - ``sha512`` as a ``hashalg`` argument. - - -Internals ---------- - -- Move ``TopologicalSorter`` from ``pyramid.config.util`` to ``pyramid.util``, - move ``CyclicDependencyError`` from ``pyramid.config.util`` to - ``pyramid.exceptions``, rename ``Singleton`` to ``Sentinel`` and move from - ``pyramid.config.util`` to ``pyramid.util``; this is in an effort to - move that stuff that may be an API one day out of ``pyramid.config.util``, - because that package should never be imported from non-Pyramid code. - TopologicalSorter is still not an API, but may become one. - -- Get rid of shady monkeypatching of ``pyramid.request.Request`` and - ``pyramid.response.Response`` done within the ``__init__.py`` of Pyramid. - Webob no longer relies on this being done. Instead, the ResponseClass - attribute of the Pyramid Request class is assigned to the Pyramid response - class; that's enough to satisfy WebOb and behave as it did before with the - monkeypatching. - -1.4a3 (2012-10-26) -================== - -Bug Fixes ---------- - -- The match_param predicate's text method was fixed to sort its values. - Part of https://github.com/Pylons/pyramid/pull/705 - -- 1.4a ``pyramid.scripting.prepare`` behaved differently than 1.3 series - function of same name. In particular, if passed a request, it would not - set the ``registry`` attribute of the request like 1.3 did. A symptom - would be that passing a request to ``pyramid.paster.bootstrap`` (which uses - the function) that did not have a ``registry`` attribute could assume that - the registry would be attached to the request by Pyramid. This assumption - could be made in 1.3, but not in 1.4. The assumption can now be made in - 1.4 too (a registry is attached to a request passed to bootstrap or - prepare). - -- When registering a view configuration that named a Chameleon ZPT renderer - with a macro name in it (e.g. ``renderer='some/template#somemacro.pt``) as - well as a view configuration without a macro name in it that pointed to the - same template (e.g. ``renderer='some/template.pt'``), internal caching could - confuse the two, and your code might have rendered one instead of the - other. - -Features --------- +- The ``alchemy`` scaffold tests now provide better coverage. See + https://github.com/Pylons/pyramid/pull/1029 -- Allow multiple values to be specified to the ``request_param`` view/route - predicate as a sequence. Previously only a single string value was allowed. - See https://github.com/Pylons/pyramid/pull/705 - -- Comments with references to documentation sections placed in scaffold - ``.ini`` files. - -- Added an HTTP Basic authentication policy - at ``pyramid.authentication.BasicAuthAuthenticationPolicy``. - -- The Configurator ``testing_securitypolicy`` method now returns the policy - object it creates. - -- The Configurator ``testing_securitypolicy`` method accepts two new - arguments: ``remember_result`` and ``forget_result``. If supplied, these - values influence the result of the policy's ``remember`` and ``forget`` - methods, respectively. - -- The DummySecurityPolicy created by ``testing_securitypolicy`` now sets a - ``forgotten`` value on the policy (the value ``True``) when its ``forget`` - method is called. - -- The DummySecurityPolicy created by ``testing_securitypolicy`` now sets a - ``remembered`` value on the policy, which is the value of the ``principal`` - argument it's called with when its ``remember`` method is called. - -- New ``physical_path`` view predicate. If specified, this value should be a - string or a tuple representing the physical traversal path of the context - found via traversal for this predicate to match as true. For example: - ``physical_path='/'`` or ``physical_path='/a/b/c'`` or ``physical_path=('', - 'a', 'b', 'c')``. This is not a path prefix match or a regex, it's a - whole-path match. It's useful when you want to always potentially show a - view when some object is traversed to, but you can't be sure about what kind - of object it will be, so you can't use the ``context`` predicate. The - individual path elements inbetween slash characters or in tuple elements - should be the Unicode representation of the name of the resource and should - not be encoded in any way. - -1.4a2 (2012-09-27) -================== +- The ``pyramid.config.Configurator.add_route`` method now supports being + called with an external URL as pattern. See + https://github.com/Pylons/pyramid/issues/611 and the documentation section + in the "URL Dispatch" chapter entitled "External Routes" for more information. Bug Fixes --------- -- When trying to determine Mako defnames and Chameleon macro names in asset - specifications, take into account that the filename may have a hyphen in - it. See https://github.com/Pylons/pyramid/pull/692 - -Features --------- - -- A new ``pyramid.session.check_csrf_token`` convenience function was added. - -- A ``check_csrf`` view predicate was added. For example, you can now do - ``config.add_view(someview, check_csrf=True)``. When the predicate is - checked, if the ``csrf_token`` value in ``request.params`` matches the CSRF - token in the request's session, the view will be permitted to execute. - Otherwise, it will not be permitted to execute. - -- Add ``Base.metadata.bind = engine`` to alchemy template, so that tables - defined imperatively will work. - -Documentation -------------- +- It was not possible to use ``pyramid.httpexceptions.HTTPException`` as + the ``context`` of an exception view as very general catchall for + http-related exceptions when you wanted that exception view to override the + default exception view. See https://github.com/Pylons/pyramid/issues/985 + +- When the ``pyramid.reload_templates`` setting was true, and a Chameleon + template was reloaded, and the renderer specification named a macro + (e.g. ``foo#macroname.pt``), renderings of the template after the template + was reloaded due to a file change would produce the entire template body + instead of just a rendering of the macro. See + https://github.com/Pylons/pyramid/issues/1013. + +- Fix an obscure problem when combining a virtual root with a route with a + ``*traverse`` in its pattern. Now the traversal path generated in + such a configuration will be correct, instead of an element missing + a leading slash. + +- Fixed a Mako renderer bug returning a tuple with a previous defname value + in some circumstances. See https://github.com/Pylons/pyramid/issues/1037 + for more information. + +- Make the ``pyramid.config.assets.PackageOverrides`` object implement the API + for ``__loader__`` objects specified in PEP 302. Proxies to the + ``__loader__`` set by the importer, if present; otherwise, raises + ``NotImplementedError``. This makes Pyramid static view overrides work + properly under Python 3.3 (previously they would not). See + https://github.com/Pylons/pyramid/pull/1015 for more information. + +- ``mako_templating``: added defensive workaround for non-importability of + ``mako`` due to upstream ``markupsafe`` dropping Python 3.2 support. Mako + templating will no longer work under the combination of MarkupSafe 0.17 and + Python 3.2 (although the combination of MarkupSafe 0.17 and Python 3.3 or any + supported Python 2 version will work OK). -- update wiki2 SQLA tutorial with the changes required after inserting - ``Base.metadata.bind = engine`` into the alchemy scaffold. - -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 +- Spaces and dots may now be in mako renderer template paths. This was + broken when support for the new makodef syntax was added in 1.4a1. + See https://github.com/Pylons/pyramid/issues/950 -- 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 +- ``pyramid.debug_authorization=true`` will now correctly print out + ``Allowed`` for views registered with ``NO_PERMISSION_REQUIRED`` instead + of invoking the ``permits`` method of the authorization policy. + See https://github.com/Pylons/pyramid/issues/954 -- 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. +- Pyramid failed to install on some systems due to being packaged with + some test files containing higher order characters in their names. These + files have now been removed. See + https://github.com/Pylons/pyramid/issues/981 -Features --------- +- ``pyramid.testing.DummyResource`` didn't define ``__bool__``, so code under + Python 3 would use ``__len__`` to find truthiness; this usually caused an + instance of DummyResource to be "falsy" instead of "truthy". See + https://github.com/Pylons/pyramid/pull/1032 -- 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 - Not Found 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 ``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. +- The ``alchemy`` scaffold would break when the database was MySQL during + tables creation. See https://github.com/Pylons/pyramid/pull/1049 -Deprecations ------------- +- The ``current_route_url`` method now attaches the query string to the URL by + default. See + https://github.com/Pylons/pyramid/issues/1040 -- 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). +- Make ``pserve.cherrypy_server_runner`` Python 3 compatible. See + https://github.com/Pylons/pyramid/issues/718 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. +- Modified the ``current_route_url`` method in pyramid.Request. The method + previously returned the URL without the query string by default, it now does + attach the query string unless it is overriden. + +- The ``route_url`` and ``route_path`` APIs no longer quote ``/`` + to ``%2F`` when a replacement value contains a ``/``. This was pointless, + as WSGI servers always unquote the slash anyway, and Pyramid never sees the + quoted value. + +- It is no longer possible to set a ``locale_name`` attribute of the request, + nor is it possible to set a ``localizer`` attribute of the request. These + are now "reified" properties that look up a locale name and localizer + respectively using the machinery described in the "Internationalization" + chapter of the documentation. + +- If you send an ``X-Vhm-Root`` header with a value that ends with a slash (or + any number of slashes), the trailing slash(es) will be removed before a URL + is generated when you use use ``request.resource_url`` or + ``request.resource_path``. Previously the virtual root path would not have + trailing slashes stripped, which would influence URL generation. + +- The ``pyramid.interfaces.IResourceURL`` interface has now grown two new + attributes: ``virtual_path_tuple`` and ``physical_path_tuple``. These should + be the tuple form of the resource's path (physical and virtual). |