Navigation

An event is an object broadcast by the Pyramid framework at
interesting points during the lifetime of an application. You don't need to
use events in order to create most Pyramid applications, but they can be
useful when you want to perform slightly advanced operations. For example,
subscribing to an event can allow you to run some code as the result of every
new request.

Events in Pyramid are always broadcast by the framework. However, they
only become useful when you register a subscriber. A subscriber is a
function that accepts a single argument named event:

1
2

defmysubscriber(event):print(event)

The above is a subscriber that simply prints the event to the console when it's
called.

When the subscriber() decorator is used, a scan
must be performed against the package containing the decorated function for the
decorator to have any effect.

Either of the above registration examples implies that every time the
Pyramid framework emits an event object that supplies an
pyramid.events.NewRequest interface, the mysubscriber function
will be called with an event object.

You may configure these functions to be called at the appropriate times by
adding the following code to your application's configuration startup:

1
2
3
4
5
6

# config is an instance of pyramid.config.Configuratorconfig.add_subscriber('myproject.subscribers.handle_new_request','pyramid.events.NewRequest')config.add_subscriber('myproject.subscribers.handle_new_response','pyramid.events.NewResponse')

Either mechanism causes the functions in subscribers.py to be registered as
event subscribers. Under this configuration, when the application is run, each
time a new request or response is detected, a message will be printed to the
console.

Each of our subscriber functions accepts an event object and prints an
attribute of the event object. This begs the question: how can we know which
attributes a particular event has?

In addition to using the events that the Pyramid framework creates, you can
create your own events for use in your application. This can be useful to
decouple parts of your application.

For example, suppose your application has to do many things when a new document
is created. Rather than putting all this logic in the view that creates the
document, you can create the document in your view and then fire a custom
event. Subscribers to the custom event can take other actions, such as indexing
the document, sending email, or sending a message to a remote system.

An event is simply an object. There are no required attributes or method for
your custom events. In general, your events should keep track of the
information that subscribers will need. Here are some example custom event
classes:

Some Pyramid applications choose to define custom events classes in an
events module.

You can subscribe to custom events in the same way that you subscribe to
Pyramid events—either imperatively or with a decorator. You can also use custom
events with subscriber predicates. Here's an
example of subscribing to a custom event with a decorator:

This example view will notify all subscribers to the custom DocCreated
event.

Note that when you fire an event, all subscribers are run synchronously so it's
generally not a good idea to create event handlers that may take a long time to
run. Although event handlers could be used as a central place to spawn tasks on
your own message queues.