(Actually, xmpppy has facilities for async operation. But not enough of the code uses it.)
Anyway, I started writing a Python module that would do Jabber asynchronously. Then I realized the easiest way to do that was to build a framework which could do anything asynchronously, and then write a Jabber extension for it. (The theory is similar to the POE module in Perl.)
"But wait!" you cry. "What about Twisted Python? Isn't that exactly what you're describing?"
Well, yes. It is. Only I didn't discover Twisted until I was finished with my framework. (Actually, it's worse: I discovered Twisted when I had one more day of work left to do on my framework.)
Now I have this thing. It's a shining example of Not Invented Here-ism. I could have thrown it away and rewritten all of my project code to use Twisted. But I haven't done that, and I do (of course) find my system comfortable to use. So I'm sticking with it, for the moment.
The least I can do is offer it for you to use, too.
Note: Zymb is in an early state of development. I have tested all the parts that I've written, but I may write more parts as my Volity work continues. Watch this space, if you're interested.
Zymb is written in pure Python, so you don't need to compile anything.
Download, unpack, and set your PYTHONPATH environment variable
to point at the directory containing the zymb subdirectory.
Start trying the examples.
(Nitpickers, who nonetheless have a point, will note that Zymb isn't absolutely async. There are some blocking operations in the Python standard library and, indeed, in the C libraries that underlie Python. For example: socket connection and SSL negotiation will block for some amount of time. There's no way around that without using threads, or else doing a lot of work to reimplement SSL and DNS libraries. So it's more accurate to say that Zymb is... pretty darn asynchronous for a non-threaded pure Python module can be. In the interests of disclosure, I am told that Twisted has done this reimplementation work. Good for them.)
Anyhow:
There's an agent which reads from stdin using readline. However, I had to hack up the Python readline module (adding more APIs) to make it work. So that's probably useless to you, unless you want to recompile the readline module (C code). If you do, here it is -- feel free.
And there's the Jabber agent, which is what I've spent most of my time on. It allows you to write Jabber clients. (Jabber servers are certainly also possible, but I haven't worked on that at all.)
I have some high-level facilities for Jabber-RPC and Service Discovery. ("High-level" meaning you can send and receive these kinds of messages without mucking about in XML stanzas.) This where the model really shows itself off.
After a certain amount of work -- yes, Zymb 1.2.4 can. However, Google's implementation is kind of funky, so there are a few issues that you have to pay attention to.
First, when you create a Jabber agent, you have to supply a host
argument as well as a JID:
cl = zymb.jabber.client.JabberAuthResource('id@gmail.com', 'password', host='talk.google.com')
Second, Google Talk only passes messages between JIDs that are on each
others' rosters. (This differs from the other Jabber implementations I've
seen, which are willing to pass messages to strangers.) And third,
Google Talk does not pass <iq> packets. So you're not going to be
able to set up Service Discovery or Jabber-RPC.
<http://eblong.com/zarf/zymb/>.