XMPP Publish/Subscribe (described in XEP-0060) is a way to send change notifications in near real-time over the XMPP messaging network. This can be used for blogs, news feeds, status notification, etc.
There are many Free Software XMPP servers out there, some of which support Publish/Subscribe (such as ejabberd and OpenFire), but there are few client-side libraries available. Two possibilities I've found are Gloox, a C++ library with Publish/Subscribe support in development, and x60br, a Python library using the famous Twisted framework for asynchronous capabilities.
PubSubClient offers a Python interface to XMPP Publish/Subscribe, similar to x60br, but using native Python types and its own convenience classes (currently PubSubClient, Server, Node and JID). This is to make application development more familiar to those who know Python but not frameworks such as Twisted (which is rarely used in, for example, the desktop application space). PubSubClient is still heavily in development and is not recommended for serious use at the moment. PubSubClient's code can be found on GitHub (using the Git distributed version control system).
PubSubClient's approach to the asynchronous world of instant messaging is to use a callback system, where every outgoing method can be passed a function which is executed when a reply is received.
PubSubClient uses the xmpppy library for sending and receiving XMPP messages and the lxml library for handling the XML involved. This is, however, transparent to application developers who do not need to deal with those libraries in order to use PubSubClient.
The pubsubclient.PubSubClient class contains methods to send everything defined in the Publish-Subscribe specification. The class's constructor is passed a JID (either a string or a JID object) and a password (string), then its connect method needs to be executed. Once connected its Publish-Subscribe methods can be called, and optionally given callbacks (return_functions). The PubSubClient then needs its process method called periodically in order to handle any messages which have arrived since the last process call.
Since XMPP Core requires that the "iq" stanzas used in Publish-Subscribe have an ID which is included in any reply, the callback functions are stored in a dictionary with the stanza IDs as their keys. When messages are received the dictionaries are queried for its ID, and if found then the function it maps to is executed.
This actually uses two stages, there are handler functions defined inside each method which make useful Pythonic representations of the incoming data, and are stored in a separate dictionary to the developer-defined callback function. These handlers then call the callback functions and pass on the Pythonic information. Each method can require its callback to accept specific arguments, since "get_children" necessarily needs to pass its callback different data structures to "publish", for example.
In order to develop a library like PubSubClient it is necessary to have some tests to make sure it is working. PubSubClient comes with three tests so far, all written in PyGTK (but PubSubClient itself is toolkit and interface independent).
There is a "browser" application which displays the nodes on a given server in a tree structure, allows adding and removing nodes from servers and changing node owners, publishers and those banned from a node. This requires PyGTK and Kiwi.
There is a "reader" application which is similar in form and function to many news reader applications such as Liferea and Akregator. This is still heavily in development, and thus is not particularly useful at the moment. This requires PyGTK, Kiwi and Python GTK Webkit bindings.
There is a "writer" application, designed to work in a similar way to offline blogging applications such as KBlogger and BloGTK. Still rather unusable at the moment. This requires PyGTK.