| commit | author | age | ||
| 1608b2 | 1 | 1.4b1 (2012-11-21) |
| CM | 2 | ================== |
| 0ccdc2 | 3 | |
| 71cd93 | 4 | Features |
| CM | 5 | -------- |
| 6 | ||
| 7 | - Small microspeed enhancement which anticipates that a | |
| 8 | ``pyramid.response.Response`` object is likely to be returned from a view. | |
| 9 | Some code is shortcut if the class of the object returned by a view is this | |
| 10 | class. A similar microoptimization was done to | |
| 11 | ``pyramid.request.Request.is_response``. | |
| 12 | ||
| 9132f6 | 13 | - Make it possible to use variable arguments on ``p*`` commands (``pserve``, |
| CM | 14 | ``pshell``, ``pviews``, etc) in the form ``a=1 b=2`` so you can fill in |
| 15 | values in parameterized ``.ini`` file, e.g. ``pshell etc/development.ini | |
| 6ba0fc | 16 | http_port=8080``. See https://github.com/Pylons/pyramid/pull/714 |
| 9132f6 | 17 | |
| f700d3 | 18 | - A somewhat advanced and obscure feature of Pyramid event handlers is their |
| CM | 19 | ability to handle "multi-interface" notifications. These notifications have |
| 20 | traditionally presented multiple objects to the subscriber callable. For | |
| 21 | instance, if an event was sent by code like this:: | |
| 28fc3d | 22 | |
| CM | 23 | registry.notify(event, context) |
| 24 | ||
| 25 | In the past, in order to catch such an event, you were obligated to write and | |
| 26 | register an event subscriber that mentioned both the event and the context in | |
| 27 | its argument list:: | |
| 28 | ||
| 29 | @subscriber([SomeEvent, SomeContextType]) | |
| f700d3 | 30 | def asubscriber(event, context): |
| 28fc3d | 31 | pass |
| CM | 32 | |
| f700d3 | 33 | In many subscriber callables registered this way, it was common for the logic |
| CM | 34 | in the subscriber callable to completely ignore the second and following |
| 35 | arguments (e.g. ``context`` in the above example might be ignored), because | |
| 36 | they usually existed as attributes of the event anyway. You could usually | |
| a3810e | 37 | get the same value by doing ``event.context`` or similar. |
| f700d3 | 38 | |
| CM | 39 | The fact that you needed to put an extra argument which you usually ignored |
| 40 | in the subscriber callable body was only a minor annoyance until we added | |
| a3810e | 41 | "subscriber predicates", used to narrow the set of circumstances under which |
| CM | 42 | a subscriber will be executed, in a prior 1.4 alpha release. Once those were |
| 43 | added, the annoyance was escalated, because subscriber predicates needed to | |
| 44 | accept the same argument list and arity as the subscriber callables that they | |
| 45 | were configured against. So, for example, if you had these two subscriber | |
| 46 | registrations in your code:: | |
| 28fc3d | 47 | |
| CM | 48 | @subscriber([SomeEvent, SomeContextType]) |
| f700d3 | 49 | def asubscriber(event, context): |
| CM | 50 | pass |
| 51 | ||
| 52 | @subscriber(SomeOtherEvent) | |
| 53 | def asubscriber(event): | |
| 54 | pass | |
| 55 | ||
| 56 | And you wanted to use a subscriber predicate:: | |
| 57 | ||
| 58 | @subscriber([SomeEvent, SomeContextType], mypredicate=True) | |
| a3810e | 59 | def asubscriber1(event, context): |
| f700d3 | 60 | pass |
| CM | 61 | |
| 62 | @subscriber(SomeOtherEvent, mypredicate=True) | |
| a3810e | 63 | def asubscriber2(event): |
| f700d3 | 64 | pass |
| CM | 65 | |
| a3810e | 66 | If an existing ``mypredicate`` subscriber predicate had been written in such |
| CM | 67 | a way that it accepted only one argument in its ``__call__``, you could not |
| 68 | use it against a subscription which named more than one interface in its | |
| 69 | subscriber interface list. Similarly, if you had written a subscriber | |
| 70 | predicate that accepted two arguments, you couldn't use it against a | |
| 71 | registration that named only a single interface type. | |
| 72 | ||
| 73 | For example, if you created this predicate:: | |
| f700d3 | 74 | |
| CM | 75 | class MyPredicate(object): |
| 76 | # portions elided... | |
| 77 | def __call__(self, event): | |
| 78 | return self.val == event.context.foo | |
| 79 | ||
| a3810e | 80 | It would not work against a multi-interface-registered subscription, so in |
| CM | 81 | the above example, when you attempted to use it against ``asubscriber1``, it |
| 82 | would fail at runtime with a TypeError, claiming something was attempting to | |
| 83 | call it with too many arguments. | |
| f700d3 | 84 | |
| a3810e | 85 | To hack around this limitation, you were obligated to design the |
| CM | 86 | ``mypredicate`` predicate to expect to receive in its ``__call__`` either a |
| 87 | single ``event`` argument (a SomeOtherEvent object) *or* a pair of arguments | |
| 88 | (a SomeEvent object and a SomeContextType object), presumably by doing | |
| 89 | something like this:: | |
| f700d3 | 90 | |
| CM | 91 | class MyPredicate(object): |
| 92 | # portions elided... | |
| 93 | def __call__(self, event, context=None): | |
| 94 | return self.val == event.context.foo | |
| 95 | ||
| 96 | This was confusing and bad. | |
| 97 | ||
| 98 | In order to allow people to ignore unused arguments to subscriber callables | |
| 99 | and to normalize the relationship between event subscribers and subscriber | |
| 100 | predicates, we now allow both subscribers and subscriber predicates to accept | |
| 101 | only a single ``event`` argument even if they've been subscribed for | |
| 102 | notifications that involve multiple interfaces. Subscribers and subscriber | |
| 103 | predicates that accept only one argument will receive the first object passed | |
| 104 | to ``notify``; this is typically (but not always) the event object. The | |
| 105 | other objects involved in the subscription lookup will be discarded. You can | |
| 106 | now write an event subscriber that accepts only ``event`` even if it | |
| 107 | subscribes to multiple interfaces:: | |
| 108 | ||
| 109 | @subscriber([SomeEvent, SomeContextType]) | |
| 110 | def asubscriber(event): | |
| 28fc3d | 111 | # this will work! |
| CM | 112 | |
| f700d3 | 113 | This prevents you from needing to match the subscriber callable parameters to |
| CM | 114 | the subscription type unnecessarily, especially when you don't make use of |
| 115 | any argument in your subscribers except for the event object itself. | |
| 116 | ||
| 117 | Note, however, that if the event object is not the first | |
| 118 | object in the call to ``notify``, you'll run into trouble. For example, if | |
| 119 | notify is called with the context argument first:: | |
| 28fc3d | 120 | |
| CM | 121 | registry.notify(context, event) |
| 122 | ||
| f700d3 | 123 | You won't be able to take advantage of the event-only feature. It will |
| CM | 124 | "work", but the object received by your event handler won't be the event |
| 125 | object, it will be the context object, which won't be very useful:: | |
| 28fc3d | 126 | |
| CM | 127 | @subscriber([SomeContextType, SomeEvent]) |
| f700d3 | 128 | def asubscriber(event): |
| 28fc3d | 129 | # bzzt! you'll be getting the context here as ``event``, and it'll |
| CM | 130 | # be useless |
| 131 | ||
| 132 | Existing multiple-argument subscribers continue to work without issue, so you | |
| 133 | should continue use those if your system notifies using multiple interfaces | |
| 134 | and the first interface is not the event interface. For example:: | |
| 135 | ||
| 136 | @subscriber([SomeContextType, SomeEvent]) | |
| f700d3 | 137 | def asubscriber(context, event): |
| 28fc3d | 138 | # this will still work! |
| CM | 139 | |
| 140 | The event-only feature makes it possible to use a subscriber predicate that | |
| 141 | accepts only a request argument within both multiple-interface subscriber | |
| f700d3 | 142 | registrations and single-interface subscriber registrations. You needn't |
| CM | 143 | make slightly different variations of predicates depending on the |
| 144 | subscription type arguments. Instead, just write all your subscriber | |
| 145 | predicates so they only accept ``event`` in their ``__call__`` and they'll be | |
| 146 | useful across all registrations for subscriptions that use an event as their | |
| 147 | first argument, even ones which accept more than just ``event``. | |
| 28fc3d | 148 | |
| f700d3 | 149 | However, the same caveat applies to predicates as to subscriber callables: if |
| CM | 150 | you're subscribing to a multi-interface event, and the first interface is not |
| 151 | the event interface, the predicate won't work properly. In such a case, | |
| 152 | you'll need to match the predicate ``__call__`` argument ordering and | |
| 153 | composition to the ordering of the interfaces. For example, if the | |
| 154 | registration for the subscription uses ``[SomeContext, SomeEvent]``, you'll | |
| 155 | need to reflect that in the ordering of the parameters of the predicate's | |
| 156 | ``__call__`` method:: | |
| 28fc3d | 157 | |
| CM | 158 | def __call__(self, context, event): |
| 159 | return event.request.path.startswith(self.val) | |
| 160 | ||
| f700d3 | 161 | tl;dr: 1) When using multi-interface subscriptions, always use the event type |
| CM | 162 | as the first subscription registration argument and 2) When 1 is true, use |
| 163 | only ``event`` in your subscriber and subscriber predicate parameter lists, | |
| 164 | no matter how many interfaces the subscriber is notified with. This | |
| 165 | combination will result in the maximum amount of reusability of subscriber | |
| 166 | predicates and the least amount of thought on your part. Drink responsibly. | |
| 28fc3d | 167 | |
| 0ccdc2 | 168 | Bug Fixes |
| CM | 169 | --------- |
| 170 | ||
| 171 | - A failure when trying to locate the attribute ``__text__`` on route and view | |
| 172 | predicates existed when the ``debug_routematch`` setting was true or when the | |
| 173 | ``pviews`` command was used. See https://github.com/Pylons/pyramid/pull/727 | |
| 174 | ||
| b5e444 | 175 | Documentation |
| CM | 176 | ------------- |
| 177 | ||
| 178 | - Sync up tutorial source files with the files that are rendered by the | |
| 179 | scaffold that each uses. | |
| 180 | ||
| 948068 | 181 | 1.4a4 (2012-11-14) |
| CM | 182 | ================== |
| c7337b | 183 | |
| CM | 184 | Features |
| 185 | -------- | |
| 186 | ||
| 19b820 | 187 | - ``pyramid.authentication.AuthTktAuthenticationPolicy`` has been updated to |
| MM | 188 | support newer hashing algorithms such as ``sha512``. Existing applications |
| 39ef68 | 189 | should consider updating if possible for improved security over the default |
| CM | 190 | md5 hashing. |
| 19b820 | 191 | |
| c7337b | 192 | - Added an ``effective_principals`` route and view predicate. |
| CM | 193 | |
| 07c9ee | 194 | - Do not allow the userid returned from the ``authenticated_userid`` or the |
| CM | 195 | userid that is one of the list of principals returned by |
| 196 | ``effective_principals`` to be either of the strings ``system.Everyone`` or | |
| 197 | ``system.Authenticated`` when any of the built-in authorization policies that | |
| 198 | live in ``pyramid.authentication`` are in use. These two strings are | |
| 199 | reserved for internal usage by Pyramid and they will not be accepted as valid | |
| 200 | userids. | |
| 201 | ||
| ca4656 | 202 | - Slightly better debug logging from |
| MM | 203 | ``pyramid.authentication.RepozeWho1AuthenticationPolicy``. |
| 47146e | 204 | |
| 39ef68 | 205 | - ``pyramid.security.view_execution_permitted`` used to return ``True`` if no |
| 926fb6 | 206 | view could be found. It now raises a ``TypeError`` exception in that case, as |
| CM | 207 | it doesn't make sense to assert that a nonexistent view is |
| 208 | execution-permitted. See https://github.com/Pylons/pyramid/issues/299. | |
| cb745b | 209 | |
| a8d71c | 210 | - Allow a ``_depth`` argument to ``pyramid.view.view_config``, which will |
| CM | 211 | permit limited composition reuse of the decorator by other software that |
| 212 | wants to provide custom decorators that are much like view_config. | |
| 213 | ||
| 170124 | 214 | - Allow an iterable of decorators to be passed to |
| MM | 215 | ``pyramid.config.Configurator.add_view``. This allows views to be wrapped |
| 216 | by more than one decorator without requiring combining the decorators | |
| 217 | yourself. | |
| 218 | ||
| a007a4 | 219 | Bug Fixes |
| CM | 220 | --------- |
| 221 | ||
| 222 | - In the past if a renderer returned ``None``, the body of the resulting | |
| 223 | response would be set explicitly to the empty string. Instead, now, the body | |
| 224 | is left unchanged, which allows the renderer to set a body itself by using | |
| 225 | e.g. ``request.response.body = b'foo'``. The body set by the renderer will | |
| 226 | be unmolested on the way out. See | |
| 227 | https://github.com/Pylons/pyramid/issues/709 | |
| 228 | ||
| 34d4cd | 229 | - In uncommon cases, the ``pyramid_excview_tween_factory`` might have |
| CM | 230 | inadvertently raised a ``KeyError`` looking for ``request_iface`` as an |
| 231 | attribute of the request. It no longer fails in this case. See | |
| 232 | https://github.com/Pylons/pyramid/issues/700 | |
| 048754 | 233 | |
| 267dbd | 234 | - Be more tolerant of potential error conditions in ``match_param`` and |
| CM | 235 | ``physical_path`` predicate implementations; instead of raising an exception, |
| 236 | return False. | |
| 237 | ||
| 39ef68 | 238 | - ``pyramid.view.render_view`` was not functioning properly under Python 3.x |
| CM | 239 | due to a byte/unicode discrepancy. See |
| f89cfc | 240 | http://github.com/Pylons/pyramid/issues/721 |
| MM | 241 | |
| ca3df8 | 242 | Deprecations |
| MM | 243 | ------------ |
| 244 | ||
| 39ef68 | 245 | - ``pyramid.authentication.AuthTktAuthenticationPolicy`` will emit a warning if |
| CM | 246 | an application is using the policy without explicitly passing a ``hashalg`` |
| 247 | argument. This is because the default is "md5" which is considered | |
| 248 | theoretically subject to collision attacks. If you really want "md5" then you | |
| 249 | must specify it explicitly to get rid of the warning. | |
| 250 | ||
| 251 | Documentation | |
| 252 | ------------- | |
| 253 | ||
| 254 | - All of the tutorials that use | |
| 255 | ``pyramid.authentication.AuthTktAuthenticationPolicy`` now explicitly pass | |
| 256 | ``sha512`` as a ``hashalg`` argument. | |
| 257 | ||
| ca3df8 | 258 | |
| 66fe1d | 259 | Internals |
| CM | 260 | --------- |
| 261 | ||
| 262 | - Move ``TopologicalSorter`` from ``pyramid.config.util`` to ``pyramid.util``, | |
| 263 | move ``CyclicDependencyError`` from ``pyramid.config.util`` to | |
| 264 | ``pyramid.exceptions``, rename ``Singleton`` to ``Sentinel`` and move from | |
| ca4656 | 265 | ``pyramid.config.util`` to ``pyramid.util``; this is in an effort to |
| 048754 | 266 | move that stuff that may be an API one day out of ``pyramid.config.util``, |
| 66fe1d | 267 | because that package should never be imported from non-Pyramid code. |
| CM | 268 | TopologicalSorter is still not an API, but may become one. |
| 269 | ||
| 39ef68 | 270 | - Get rid of shady monkeypatching of ``pyramid.request.Request`` and |
| CM | 271 | ``pyramid.response.Response`` done within the ``__init__.py`` of Pyramid. |
| 272 | Webob no longer relies on this being done. Instead, the ResponseClass | |
| 273 | attribute of the Pyramid Request class is assigned to the Pyramid response | |
| 274 | class; that's enough to satisfy WebOb and behave as it did before with the | |
| 275 | monkeypatching. | |
| 276 | ||
| 4a6cca | 277 | 1.4a3 (2012-10-26) |
| CM | 278 | ================== |
| d6fb00 | 279 | |
| CM | 280 | Bug Fixes |
| 281 | --------- | |
| 282 | ||
| 06a904 | 283 | - The match_param predicate's text method was fixed to sort its values. |
| CM | 284 | Part of https://github.com/Pylons/pyramid/pull/705 |
| 285 | ||
| d6fb00 | 286 | - 1.4a ``pyramid.scripting.prepare`` behaved differently than 1.3 series |
| CM | 287 | function of same name. In particular, if passed a request, it would not |
| 288 | set the ``registry`` attribute of the request like 1.3 did. A symptom | |
| 289 | would be that passing a request to ``pyramid.paster.bootstrap`` (which uses | |
| 290 | the function) that did not have a ``registry`` attribute could assume that | |
| 291 | the registry would be attached to the request by Pyramid. This assumption | |
| 292 | could be made in 1.3, but not in 1.4. The assumption can now be made in | |
| 293 | 1.4 too (a registry is attached to a request passed to bootstrap or | |
| 294 | prepare). | |
| 295 | ||
| 66d277 | 296 | - When registering a view configuration that named a Chameleon ZPT renderer |
| CM | 297 | with a macro name in it (e.g. ``renderer='some/template#somemacro.pt``) as |
| 298 | well as a view configuration without a macro name it it that pointed to the | |
| 9937a4 | 299 | same template (e.g. ``renderer='some/template.pt'``), internal caching could |
| 66d277 | 300 | confuse the two, and your code might have rendered one instead of the |
| CM | 301 | other. |
| 302 | ||
| 1273d5 | 303 | Features |
| CM | 304 | -------- |
| 305 | ||
| c25a8f | 306 | - Allow multiple values to be specified to the ``request_param`` view/route |
| CM | 307 | predicate as a sequence. Previously only a single string value was allowed. |
| 308 | See https://github.com/Pylons/pyramid/pull/705 | |
| 309 | ||
| 310 | - Comments with references to documentation sections placed in scaffold | |
| 311 | ``.ini`` files. | |
| 312 | ||
| 313 | - Added an HTTP Basic authentication policy | |
| 314 | at ``pyramid.authentication.BasicAuthAuthenticationPolicy``. | |
| 315 | ||
| 1273d5 | 316 | - The Configurator ``testing_securitypolicy`` method now returns the policy |
| CM | 317 | object it creates. |
| 318 | ||
| 319 | - The Configurator ``testing_securitypolicy`` method accepts two new | |
| 320 | arguments: ``remember_result`` and ``forget_result``. If supplied, these | |
| 321 | values influence the result of the policy's ``remember`` and ``forget`` | |
| 322 | methods, respectively. | |
| 323 | ||
| 324 | - The DummySecurityPolicy created by ``testing_securitypolicy`` now sets a | |
| 325 | ``forgotten`` value on the policy (the value ``True``) when its ``forget`` | |
| 326 | method is called. | |
| 327 | ||
| 328 | - The DummySecurityPolicy created by ``testing_securitypolicy`` now sets a | |
| 329 | ``remembered`` value on the policy, which is the value of the ``principal`` | |
| 330 | argument it's called with when its ``remember`` method is called. | |
| 331 | ||
| c25a8f | 332 | - New ``physical_path`` view predicate. If specified, this value should be a |
| CM | 333 | string or a tuple representing the physical traversal path of the context |
| 334 | found via traversal for this predicate to match as true. For example: | |
| 335 | ``physical_path='/'`` or ``physical_path='/a/b/c'`` or ``physical_path=('', | |
| 336 | 'a', 'b', 'c')``. This is not a path prefix match or a regex, it's a | |
| 337 | whole-path match. It's useful when you want to always potentially show a | |
| 338 | view when some object is traversed to, but you can't be sure about what kind | |
| 339 | of object it will be, so you can't use the ``context`` predicate. The | |
| 340 | individual path elements inbetween slash characters or in tuple elements | |
| 341 | should be the Unicode representation of the name of the resource and should | |
| 342 | not be encoded in any way. | |
| 343 | ||
| 072cbf | 344 | 1.4a2 (2012-09-27) |
| CM | 345 | ================== |
| 68c25d | 346 | |
| d27bc7 | 347 | Bug Fixes |
| CM | 348 | --------- |
| 349 | ||
| 4388d3 | 350 | - When trying to determine Mako defnames and Chameleon macro names in asset |
| CM | 351 | specifications, take into account that the filename may have a hyphen in |
| 352 | it. See https://github.com/Pylons/pyramid/pull/692 | |
| d27bc7 | 353 | |
| 68c25d | 354 | Features |
| CM | 355 | -------- |
| 356 | ||
| 357 | - A new ``pyramid.session.check_csrf_token`` convenience function was added. | |
| 358 | ||
| 80cd0b | 359 | - A ``check_csrf`` view predicate was added. For example, you can now do |
| CM | 360 | ``config.add_view(someview, check_csrf=True)``. When the predicate is |
| 361 | checked, if the ``csrf_token`` value in ``request.params`` matches the CSRF | |
| 362 | token in the request's session, the view will be permitted to execute. | |
| 363 | Otherwise, it will not be permitted to execute. | |
| 68c25d | 364 | |
| 098599 | 365 | - Add ``Base.metadata.bind = engine`` to alchemy template, so that tables |
| CM | 366 | defined imperatively will work. |
| 367 | ||
| 368 | Documentation | |
| 369 | ------------- | |
| 370 | ||
| 371 | - update wiki2 SQLA tutorial with the changes required after inserting | |
| 372 | ``Base.metadata.bind = engine`` into the alchemy scaffold. | |
| 373 | ||
| ce1e86 | 374 | 1.4a1 (2012-09-16) |
| CM | 375 | ================== |
| f6bd88 | 376 | |
| a39dd2 | 377 | Bug Fixes |
| CM | 378 | --------- |
| 379 | ||
| 1794b4 | 380 | - Forward port from 1.3 branch: When no authentication policy was configured, |
| CM | 381 | a call to ``pyramid.security.effective_principals`` would unconditionally |
| 382 | return the empty list. This was incorrect, it should have unconditionally | |
| 383 | returned ``[Everyone]``, and now does. | |
| 8782de | 384 | |
| 3074e7 | 385 | - Explicit url dispatch regexes can now contain colons. |
| CM | 386 | https://github.com/Pylons/pyramid/issues/629 |
| 387 | ||
| e65251 | 388 | - On at least one 64-bit Ubuntu system under Python 3.2, using the |
| CM | 389 | ``view_config`` decorator caused a ``RuntimeError: dictionary changed size |
| 390 | during iteration`` exception. It no longer does. See | |
| 391 | https://github.com/Pylons/pyramid/issues/635 for more information. | |
| 392 | ||
| 8b2675 | 393 | - In Mako Templates lookup, check if the uri is already adjusted and bring |
| BL | 394 | it back to an asset spec. Normally occurs with inherited templates or |
| 395 | included components. | |
| 396 | https://github.com/Pylons/pyramid/issues/606 | |
| 397 | https://github.com/Pylons/pyramid/issues/607 | |
| 398 | ||
| 7853bc | 399 | - In Mako Templates lookup, check for absolute uri (using mako directories) |
| BL | 400 | when mixing up inheritance with asset specs. |
| 401 | https://github.com/Pylons/pyramid/issues/662 | |
| 402 | ||
| 75a8ff | 403 | - HTTP Accept headers were not being normalized causing potentially |
| MM | 404 | conflicting view registrations to go unnoticed. Two views that only |
| 405 | differ in the case ('text/html' vs. 'text/HTML') will now raise an error. | |
| 406 | https://github.com/Pylons/pyramid/pull/620 | |
| 407 | ||
| a9289d | 408 | - Forward-port from 1.3 branch: when registering multiple views with an |
| CM | 409 | ``accept`` predicate in a Pyramid application runing under Python 3, you |
| 410 | might have received a ``TypeError: unorderable types: function() < | |
| 411 | function()`` exception. | |
| 412 | ||
| de797c | 413 | Features |
| CM | 414 | -------- |
| a39dd2 | 415 | |
| d24659 | 416 | - Configurator.add_directive now accepts arbitrary callables like partials or |
| CM | 417 | objects implementing ``__call__`` which dont have ``__name__`` and |
| 418 | ``__doc__`` attributes. See https://github.com/Pylons/pyramid/issues/621 | |
| 419 | and https://github.com/Pylons/pyramid/pull/647. | |
| 420 | ||
| 95f766 | 421 | - Third-party custom view, route, and subscriber predicates can now be added |
| CM | 422 | for use by view authors via |
| 423 | ``pyramid.config.Configurator.add_view_predicate``, | |
| 424 | ``pyramid.config.Configurator.add_route_predicate`` and | |
| 425 | ``pyramid.config.Configurator.add_subscriber_predicate``. So, for example, | |
| 0196b2 | 426 | doing this:: |
| CM | 427 | |
| 428 | config.add_view_predicate('abc', my.package.ABCPredicate) | |
| 429 | ||
| 430 | Might allow a view author to do this in an application that configured that | |
| 431 | predicate:: | |
| 432 | ||
| 433 | @view_config(abc=1) | |
| 434 | ||
| 95f766 | 435 | Similar features exist for ``add_route``, and ``add_subscriber``. See |
| CM | 436 | "Adding A Third Party View, Route, or Subscriber Predicate" in the Hooks |
| 437 | chapter for more information. | |
| 0196b2 | 438 | |
| 735abf | 439 | Note that changes made to support the above feature now means that only |
| CM | 440 | actions registered using the same "order" can conflict with one another. |
| 441 | It used to be the case that actions registered at different orders could | |
| 442 | potentially conflict, but to my knowledge nothing ever depended on this | |
| 443 | behavior (it was a bit silly). | |
| 444 | ||
| de797c | 445 | - Custom objects can be made easily JSON-serializable in Pyramid by defining |
| CM | 446 | a ``__json__`` method on the object's class. This method should return |
| 447 | values natively serializable by ``json.dumps`` (such as ints, lists, | |
| 448 | dictionaries, strings, and so forth). | |
| 077fa3 | 449 | |
| e012aa | 450 | - The JSON renderer now allows for the definition of custom type adapters to |
| CM | 451 | convert unknown objects to JSON serializations. |
| 452 | ||
| 360f25 | 453 | - As of this release, the ``request_method`` predicate, when used, will also |
| CM | 454 | imply that ``HEAD`` is implied when you use ``GET``. For example, using |
| 455 | ``@view_config(request_method='GET')`` is equivalent to using | |
| 561a44 | 456 | ``@view_config(request_method=('GET', 'HEAD'))``. Using |
| 360f25 | 457 | ``@view_config(request_method=('GET', 'POST')`` is equivalent to using |
| CM | 458 | ``@view_config(request_method=('GET', 'HEAD', 'POST')``. This is because |
| 459 | HEAD is a variant of GET that omits the body, and WebOb has special support | |
| 460 | to return an empty body when a HEAD is used. | |
| 15c40a | 461 | |
| 023c88 | 462 | - ``config.add_request_method`` has been introduced to support extending |
| 2c2534 | 463 | request objects with arbitrary callables. This method expands on the |
| MM | 464 | previous ``config.set_request_property`` by supporting methods as well as |
| 465 | properties. This method now causes less code to be executed at | |
| 466 | request construction time than ``config.set_request_property`` in | |
| 467 | version 1.3. | |
| fcb209 | 468 | |
| 2c2534 | 469 | - Don't add a ``?`` to URLs generated by ``request.resource_url`` if the |
| fcb209 | 470 | ``query`` argument is provided but empty. |
| CM | 471 | |
| 2c2534 | 472 | - Don't add a ``?`` to URLs generated by ``request.route_url`` if the |
| fcb209 | 473 | ``_query`` argument is provided but empty. |
| 988035 | 474 | |
| CM | 475 | - The static view machinery now raises (rather than returns) ``HTTPNotFound`` |
| 476 | and ``HTTPMovedPermanently`` exceptions, so these can be caught by the | |
| 477 | NotFound view (and other exception views). | |
| ea009a | 478 | |
| 54d3e3 | 479 | - The Mako renderer now supports a def name in an asset spec. When the def |
| 8b55a6 | 480 | name is present in the asset spec, the system will render the template def |
| CM | 481 | within the template and will return the result. An example asset spec is |
| 482 | ``package:path/to/template#defname.mako``. This will render the def named | |
| 54d3e3 | 483 | ``defname`` inside the ``template.mako`` template instead of rendering the |
| CM | 484 | entire template. The old way of returning a tuple in the form |
| 485 | ``('defname', {})`` from the view is supported for backward compatibility, | |
| 8b55a6 | 486 | |
| CM | 487 | - The Chameleon ZPT renderer now accepts a macro name in an asset spec. When |
| 488 | the macro name is present in the asset spec, the system will render the | |
| 489 | macro listed as a ``define-macro`` and return the result instead of | |
| 490 | rendering the entire template. An example asset spec: | |
| 491 | ``package:path/to/template#macroname.pt``. This will render the macro | |
| 492 | defined as ``macroname`` within the ``template.pt`` template instead of the | |
| 493 | entire templae. | |
| 61a57e | 494 | |
| CM | 495 | - When there is a predicate mismatch exception (seen when no view matches for |
| 496 | a given request due to predicates not working), the exception now contains | |
| 497 | a textual description of the predicate which didn't match. | |
| 6b180c | 498 | |
| CM | 499 | - An ``add_permission`` directive method was added to the Configurator. This |
| 500 | directive registers a free-standing permission introspectable into the | |
| 501 | Pyramid introspection system. Frameworks built atop Pyramid can thus use | |
| 502 | the the ``permissions`` introspectable category data to build a | |
| 503 | comprehensive list of permissions supported by a running system. Before | |
| 504 | this method was added, permissions were already registered in this | |
| 505 | introspectable category as a side effect of naming them in an ``add_view`` | |
| 506 | call, this method just makes it possible to arrange for a permission to be | |
| 507 | put into the ``permissions`` introspectable category without naming it | |
| 508 | along with an associated view. Here's an example of usage of | |
| 509 | ``add_permission``:: | |
| 510 | ||
| 511 | config = Configurator() | |
| 512 | config.add_permission('view') | |
| 2c2534 | 513 | |
| 45b6e1 | 514 | - The ``UnencryptedCookieSessionFactoryConfig`` now accepts |
| MM | 515 | ``signed_serialize`` and ``signed_deserialize`` hooks which may be used |
| 516 | to influence how the sessions are marshalled (by default this is done | |
| 517 | with HMAC+pickle). | |
| 518 | ||
| 28dba0 | 519 | - ``pyramid.testing.DummyRequest`` now supports methods supplied by the |
| CM | 520 | ``pyramid.util.InstancePropertyMixin`` class such as ``set_property``. |
| 735987 | 521 | |
| CM | 522 | - Request properties and methods added via ``config.set_request_property`` or |
| 523 | ``config.add_request_method`` are now available to tweens. | |
| 524 | ||
| 525 | - Request properties and methods added via ``config.set_request_property`` or | |
| 526 | ``config.add_request_method`` are now available in the request object | |
| 527 | returned from ``pyramid.paster.bootstrap``. | |
| 528 | ||
| dc8b49 | 529 | - ``request.context`` of environment request during ``bootstrap`` is now the |
| CM | 530 | root object if a context isn't already set on a provided request. |
| 531 | ||
| 07cb8f | 532 | - The ``pyramid.decorator.reify`` function is now an API, and was added to |
| CM | 533 | the API documentation. |
| 534 | ||
| 97150c | 535 | - Added the ``pyramid.testing.testConfig`` context manager, which can be used |
| CM | 536 | to generate a configurator in a test, e.g. ``with testing.testConfig(...):``. |
| 537 | ||
| 64452e | 538 | - Users can now invoke a subrequest from within view code using a new |
| CM | 539 | ``request.invoke_subrequest`` API. |
| 37d2c2 | 540 | |
| 2c2534 | 541 | Deprecations |
| MM | 542 | ------------ |
| 543 | ||
| 9cdb28 | 544 | - The ``pyramid.config.Configurator.set_request_property`` has been |
| CM | 545 | documentation-deprecated. The method remains usable but the more |
| 023c88 | 546 | featureful ``pyramid.config.Configurator.add_request_method`` should be |
| 9cdb28 | 547 | used in its place (it has all of the same capabilities but can also extend |
| CM | 548 | the request object with methods). |
| ebcdc7 | 549 | |
| CM | 550 | Backwards Incompatibilities |
| 551 | --------------------------- | |
| 552 | ||
| 25d3dd | 553 | - The Pyramid router no longer adds the values ``bfg.routes.route`` or |
| ebcdc7 | 554 | ``bfg.routes.matchdict`` to the request's WSGI environment dictionary. |
| CM | 555 | These values were docs-deprecated in ``repoze.bfg`` 1.0 (effectively seven |
| 556 | minor releases ago). If your code depended on these values, use | |
| 557 | request.matched_route and request.matchdict instead. | |
| 558 | ||
| 559 | - It is no longer possible to pass an environ dictionary directly to | |
| 560 | ``pyramid.traversal.ResourceTreeTraverser.__call__`` (aka | |
| 561 | ``ModelGraphTraverser.__call__``). Instead, you must pass a request | |
| 562 | object. Passing an environment instead of a request has generated a | |
| 563 | deprecation warning since Pyramid 1.1. | |
| 564 | ||
| 565 | - Pyramid will no longer work properly if you use the | |
| 566 | ``webob.request.LegacyRequest`` as a request factory. Instances of the | |
| 567 | LegacyRequest class have a ``request.path_info`` which return a string. | |
| 568 | This Pyramid release assumes that ``request.path_info`` will | |
| 569 | unconditionally be Unicode. | |
| 570 | ||
| 3d4272 | 571 | - The functions from ``pyramid.chameleon_zpt`` and ``pyramid.chameleon_text`` |
| CM | 572 | named ``get_renderer``, ``get_template``, ``render_template``, and |
| 573 | ``render_template_to_response`` have been removed. These have issued a | |
| 574 | deprecation warning upon import since Pyramid 1.0. Use | |
| 575 | ``pyramid.renderers.get_renderer()``, | |
| 576 | ``pyramid.renderers.get_renderer().implementation()``, | |
| 577 | ``pyramid.renderers.render()`` or ``pyramid.renderers.render_to_response`` | |
| 578 | respectively instead of these functions. | |
| 579 | ||
| 94a6f3 | 580 | - The ``pyramid.configuration`` module was removed. It had been deprecated |
| CM | 581 | since Pyramid 1.0 and printed a deprecation warning upon its use. Use |
| 582 | ``pyramid.config`` instead. | |
| 583 | ||
| b274d0 | 584 | - The ``pyramid.paster.PyramidTemplate`` API was removed. It had been |
| CM | 585 | deprecated since Pyramid 1.1 and issued a warning on import. If your code |
| 586 | depended on this, adjust your code to import | |
| 587 | ``pyramid.scaffolds.PyramidTemplate`` instead. | |
| 588 | ||
| ef2e51 | 589 | - The ``pyramid.settings.get_settings()`` API was removed. It had been |
| CM | 590 | printing a deprecation warning since Pyramid 1.0. If your code depended on |
| 591 | this API, use ``pyramid.threadlocal.get_current_registry().settings`` | |
| 592 | instead or use the ``settings`` attribute of the registry available from | |
| 593 | the request (``request.registry.settings``). | |
| 594 | ||
| 69e0aa | 595 | - These APIs from the ``pyramid.testing`` module were removed. They have |
| CM | 596 | been printing deprecation warnings since Pyramid 1.0: |
| 597 | ||
| 598 | * ``registerDummySecurityPolicy``, use | |
| 599 | ``pyramid.config.Configurator.testing_securitypolicy`` instead. | |
| 600 | ||
| 601 | * ``registerResources`` (aka ``registerModels``, use | |
| 602 | ``pyramid.config.Configurator.testing_resources`` instead. | |
| 603 | ||
| 604 | * ``registerEventListener``, use | |
| 605 | ``pyramid.config.Configurator.testing_add_subscriber`` instead. | |
| 606 | ||
| 607 | * ``registerTemplateRenderer`` (aka `registerDummyRenderer``), use | |
| 608 | ``pyramid.config.Configurator.testing_add_template`` instead. | |
| 609 | ||
| 610 | * ``registerView``, use ``pyramid.config.Configurator.add_view`` instead. | |
| 611 | ||
| 612 | * ``registerUtility``, use | |
| 613 | ``pyramid.config.Configurator.registry.registerUtility`` instead. | |
| 614 | ||
| 615 | * ``registerAdapter``, use | |
| 616 | ``pyramid.config.Configurator.registry.registerAdapter`` instead. | |
| 617 | ||
| 618 | * ``registerSubscriber``, use | |
| 619 | ``pyramid.config.Configurator.add_subscriber`` instead. | |
| 620 | ||
| 621 | * ``registerRoute``, use | |
| 622 | ``pyramid.config.Configurator.add_route`` instead. | |
| 623 | ||
| 624 | * ``registerSettings``, use | |
| 625 | ``pyramid.config.Configurator.add_settings`` instead. | |
| 626 | ||
| 64452e | 627 | - In Pyramid 1.3 and previous, the ``__call__`` method of a Response object |
| CM | 628 | was invoked before any finished callbacks were executed. As of this |
| 629 | release, the ``__call__`` method of a Response object is invoked *after* | |
| 630 | finished callbacks are executed. This is in support of the | |
| 631 | ``request.invoke_subrequest`` feature. | |
| 632 | ||
| b72ba1 | 633 | Documentation |
| CM | 634 | ------------- |
| 635 | ||
| 636 | - Added an "Upgrading Pyramid" chapter to the narrative documentation. It | |
| 07cb8f | 637 | describes how to cope with deprecations and removals of Pyramid APIs and |
| CM | 638 | how to show Pyramid-generated deprecation warnings while running tests and |
| 639 | while running a server. | |
| b72ba1 | 640 | |
| 37d2c2 | 641 | - Added a "Invoking a Subrequest" chapter to the documentation. It describes |
| 64452e | 642 | how to use the new ``request.invoke_subrequest`` API. |
| 37d2c2 | 643 | |
| ebcdc7 | 644 | Dependencies |
| CM | 645 | ------------ |
| 646 | ||
| 647 | - Pyramid now requires WebOb 1.2b3+ (the prior Pyramid release only relied on | |
| 648 | 1.2dev+). This is to ensure that we obtain a version of WebOb that returns | |
| 649 | ``request.path_info`` as text. | |
| 650 | ||
