| Age | Commit message (Collapse) | Author |
|---|
|
subscriber predicates, we now allow both subscribers and subscriber
predicates to accept only a single ``event`` argument even if they've been
subscribed for notifications that involve multiple interfaces. Subscribers
and subscriber predicates that accept only one argument will receive the
first object passed to ``notify``; this is typically (but not always) the
event object. The other objects involved in the subscription lookup will be
discarded.
For instance, if an event is sent by code like this::
registry.notify(event, context)
In the past, in order to catch such an event, you were obligated to write and
register an event subscriber that mentioned both the event and the context in
its argument list::
@subscriber([SomeEvent, SomeContextType])
def subscriber(event, context):
pass
With the event-only feature you can now write an event subscriber that
accepts only ``event`` even if it subscribes to multiple interfaces::
@subscriber([SomeEvent, SomeContextType])
def subscriber(event):
# this will work!
Note, however, that if the event object is not the first object in the call
to ``notify``, you'll run into trouble. For example, if notify is called
with the context argument first::
registry.notify(context, event)
You won't be able to take advantage of the feature. It will "work", but the
object received by your event handler won't be the event object, it will be
the context object, which won't be very useful::
@subscriber([SomeContextType, SomeEvent])
def subscriber(event):
# bzzt! you'll be getting the context here as ``event``, and it'll
# be useless
Existing multiple-argument subscribers continue to work without issue, so you
should continue use those if your system notifies using multiple interfaces
and the first interface is not the event interface. For example::
@subscriber([SomeContextType, SomeEvent])
def subscriber(context, event):
# this will still work!
The event-only feature makes it possible to use a subscriber predicate that
accepts only a request argument within both multiple-interface subscriber
registrations and single-interface subscriber registrations. In the past, if
you had a subscriber predicate like this::
class RequestPathStartsWith(object):
def __init__(self, val, config):
self.val = val
def text(self):
return 'path_startswith = %s' % (self.val,)
phash = text
def __call__(self, event):
return event.request.path.startswith(self.val)
If you attempted to use the above predicate to condition a subscription that
involved multiple interfaces, it would not work. You had to change it to
accept the same arguments as the subscription itself. For example, you might
have had to change its ``__call__`` method like so, adding a ``context``
argument::
def __call__(self, event, context):
return event.request.path.startswith(self.val)
With the event-only feature, you needn't make the change. Instead, you can
write all predicates so they only accept ``event`` in their ``__call__`` and
they'll be useful across all registrations for subscriptions that use an
event as their first argument, even ones which accept more than just
``event``. However, the same caveat applies to predicates as to
subscriptions: if you're subscribing to a multi-interface event, and the
first interface is not the event interface, the predicate won't work
properly. In such a case, you'll need to match the predicate ``__call__``
argument ordering and composition to the ordering of the interfaces. For
example::
def __call__(self, context, event):
return event.request.path.startswith(self.val)
tl;dr: 1) Always use the event as the first argument to a multi-interface
subscription and 2) Use only ``event`` in your subscriber and subscriber
predicate parameter lists, no matter how many interfaces the subscriber is
notified with, as long as the event object is the first argument passed to
``registry.notify``. This will result in the maximum amount of reusability
of subscriber predicates.
|
|
|
|
|
|
|
|
``pyramid.response.Response`` object is likely to be returned from a view.
Some code is shortcut if the class of the object returned by a view is this
class. A similar microoptimization was done to
``pyramid.request.Request.is_response``.
|
|
predicates existed when the ``debug_routematch`` setting was true or when the
``pviews`` command was used. See https://github.com/Pylons/pyramid/pull/727
Closes #727.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
``physical_path`` predicate implementations; instead of raising an exception,
return False.
|
|
|
|
permit limited compisition reuse of the decorator by other software that
wants to provide custom decorators that are much like view_config.
Closes #637.
|
|
|
|
|
|
|
|
AuthTktAuthenticationPolicy now accepts a hashalg parameter and is no
longer deprecated. Docs recommend overriding hashalg and using 'sha512'.
|
|
zope.deprecation instead of a warning, make hashalg arg a kwarg in certain cases in case someone (maybe me) is using nonapi function imports from authentication
|
|
inadvertently raised a ``KeyError`` looking for ``request_iface`` as an
attribute of the request. It no longer fails in this case. See
https://github.com/Pylons/pyramid/issues/700
Fixes #700
|
|
move ``CyclicDependencyError`` from ``pyramid.config.util`` to
``pyramid.exceptions``, rename ``Singleton`` to ``Sentinel`` and move from
``pyramid.config.util`` to ``pyramid.config.util``; this is in an effort to
move that stuff that may be an API one day out of ``pyramid.config.util,
because that package should never be imported from non-Pyramid code.
TopologicalSorter is still not an API, but may become one.
|
|
|
|
response would be set explicitly to the empty string. Instead, now, the body
is left unchanged, which allows the renderer to set a body itself by using
e.g. ``request.response.body = b'foo'``. The body set by the renderer will
be unmolested on the way out. See
https://github.com/Pylons/pyramid/issues/709
Closes #709
|
|
|
|
|
|
userid that is one of the list of principals returned by
``effective_principals`` to be either of the strings ``system.Everyone`` or
``system.Authenticated`` when any of the built-in authorization policies that
live in ``pyramid.authentication`` are in use. These two strings are
reserved for internal usage by Pyramid and they will not be accepted as valid
userids.
|
|
|
|
|
|
|
|
string or a tuple representing the physical traversal path of the context
found via traversal for this predicate to match as true. For example:
``physical_path='/'`` or ``physical_path='/a/b/c'`` or ``physical_path=('',
'a', 'b', 'c')``. This is not a path prefix match or a regex, it's a
whole-path match. It's useful when you want to always potentially show a
view when some object is traversed to, but you can't be sure about what kind
of object it will be, so you can't use the ``context`` predicate. The
individual path elements inbetween slash characters or in tuple elements
should be the Unicode representation of the name of the resource and should
not be encoded in any way.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
object it creates.
- The Configurator ``testing_securitypolicy`` method accepts two new
arguments: ``remember_result`` and ``forget_result``. If supplied, these
values influence the result of the policy's ``remember`` and ``forget``
methods, respectively.
- The DummySecurityPolicy created by ``testing_securitypolicy`` now sets a
``forgotten`` value on the policy (the value ``True``) when its ``forget``
method is called.
- The DummySecurityPolicy created by ``testing_securitypolicy`` now sets a
``remembered`` value on the policy, which is the value of the ``principal``
argument it's called with when its ``remember`` method is called.
|
|
|
|
function of same name. In particular, if passed a request, it would not
set the ``registry`` attribute of the request like 1.3 did. A symptom
would be that passing a request to ``pyramid.paster.bootstrap`` (which uses
the function) that did not have a ``registry`` attribute could assume that
the registry would be attached to the request by Pyramid. This assumption
could be made in 1.3, but not in 1.4. The assumption can now be made in
1.4 too (a registry is attached to a request passed to bootstrap or
prepare).
|
|
|
|
defined imperatively will work.
- update wiki2 SQLA tutorial with the changes required after inserting
``Base.metadata.bind = engine`` into the alchemy scaffold.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
