Back in 2004 I wrote a little Python-based web application to do XML-style search of my blog entries. It was a laboratory in which I studied structured search, microformats, in-memory data, and lightweight web applications.

Today I converted that application to IronPython. My purpose is to explore what can be done with the combination of IronPython and the .NET Framework.

I’ve reconstituted the original CPython-based searcher here:

services.jonudell.net:8000/?

The new IronPython-based searcher is here:

services.jonudell.net:8001/?

They look just the same, but you can tell which is which by looking in the browser’s title bar. One says CPython, the other IronPython.

Both are running on a Windows Server 2003 box — the same one, actually, that’s been running the CPython version for the past few years.

The code’s mostly the same too, except for the infrastructure parts. The CPython version uses the simple BaseHTTPServer that comes with Python, and it uses libxml2 for XML parsing and and libxslt for XSLT transformation. The IronPython version, instead, uses the .NET Framework’s built-in webserver (System.Net.HttpListener) and XML facilities (System.Xml).

It’s pretty much an apples-to-apples comparison, as far as these things go. Neither version is, or pretends to be, robust or scalable. Both are using bare-bones HTTP implementations in single-threaded mode, which is a technique that I find perfectly appropriate for lots of handy little services and applications that are used lightly.

The two versions seem to perform about the same on most queries as well, though the IronPython version is way faster when you use the box labeled “all paragraphs containing phrase”.

So what’s the point of this exercise? It demonstrates an unusual approach to using .NET, one that bridges between two very different cultures. In the open source realm, an enormous amount of work gets done in dynamic languages that leverage components, or modules, or libraries, to do the heavy lifting in areas like HTTP and XML. But it’s a big challenge to integrate Python with, say, libxml2, and it’s that same challenge all over again when you want to connect PHP or Ruby to libxml2.

Meanwhile, in the realm of Microsoft-oriented development, most of the work is being done in statically-typed languages. These languages also rely on components, or modules, or libraries to do the heavy lifting. But they can more effectively share the common heavy-lifting capability that’s in the .NET Framework.

The best of both worlds, I believe, is dynamic languages fully connected to common infrastructure. I’m not alone in thinking that, and the Python/.NET combo is not the only way to get there. Sean McGrath has said:

Jython, lest you do not know of it, is the most compelling weapon the Java platform has for its survival into the 21st century. [2004]

Today’s experiment confirms my hunch that IronPython will be at least as compelling, and will open up the .NET Framework to lots of folks for whom the traditional methods of access aren’t appealing.

There was one fly in the ointment. I had wanted to host this IronPython application on the Windows Communication Foundation (WCF) which would provide a much more robust engine than System.Net’s HttpListener. And at first it looked like it would work. But WCF service contracts require the use of a .NET feature called attributes. It turns out there isn’t yet a way to represent those in IronPython. If someone has figured out an intermediary that enables IronPython to implement RESTful WCF services, I’d love to see how that’s done.