RedHatTraining/pyramid.git

Chris McDonough

2013-05-22 e63bdabf6c612880ea5a9d8f38e6a00df194954e

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