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