This part of the documentation covers the Event object.

Event Objects

class, session=None)

The Event object. It structures and handles the data returned by via the Events section of the GitHub API.

Two events can be compared like so:

e1 == e2
e1 != e2

And that is equivalent to: == !=

Return the attributes for this object as a dictionary.

This is equivalent to calling:

Returns:this object’s attributes serialized to a dictionary
Return type:dict

Return the json data for this object.

This is equivalent to calling:

Returns:this object’s attributes as a JSON string
Return type:str

Return an instance of this class formed from json_dict.


Return an instance of this class formed from json.

static list_types()

List available payload types.


Number of requests before GitHub imposes a ratelimit.


Re-retrieve the information for this object.

The reasoning for the return value is the following example:

repos = [r.refresh() for r in g.repositories_by('kennethreitz')]

Without the return value, that would be an array of None’s and you would otherwise have to do:

repos = [r for i in g.repositories_by('kennethreitz')]
[r.refresh() for r in repos]

Which is really an anti-pattern.

Changed in version 0.5.

Parameters:conditional (bool) – If True, then we will search for a stored header (‘Last-Modified’, or ‘ETag’) on the object and send that as described in the Conditional Requests section of the docs

When accessing the payload of the event, you should notice that you receive a dictionary where the keys depend on the event type. Note:

  • where they reference an array in the documentation but index it like a dictionary, you are given a regular dictionary

  • where they reference a key as returning an object, you receive the equivalent object from the dictionary, e.g., for a Fork Event:

    >>> event
    <Event [Fork]>
    >>> event.payload
    {u'forkee': <Repository [eweap/redactor-js]>}
    >>> event.payload['forkee']
    <Repository [eweap/redactor-js]>

Using the dictionary returned as the payload makes far more sense than creating an object for the payload in this instance. For one, creating a class for each payload type would be insanity. I did it once, but it isn’t worth the effort. Having individual handlers as we have now which modify the payload to use our objects when available is more sensible.