IronPython: Are the batteries included?

Update: Right after I posted this, Seo Sanghyeon came up with another set of patches which address some of the issues I mention here. Pretty amazing work.

I've spent a bit of my personal time investigating IronPython. I am using ASP.NET for many of my development tasks, and I feel in love with the idea of IronPython after watching Jon Udell's screencast with Jim Hugunin, the lead developer on IronPython. There is no doubt that Jim is a super smart guy that understands how dynamic language should behave on a VM.

In my opinion, the biggest value add of IronPython is the ability to easily integrate .NET with existing Python libraries. Unfortunately, while the language itself seems very complete, there are many incompatibilities with the standard Python libraries.

I started with a simple objective of implementing OpenID consumer authentication using the JanRain OpenID python libraries. I haven't been successful.

IronPython doesn't ship with a .NET to WSGI implementation. Fortunately community members had already started working on the problem. With a little bit of massaging, we got an implementation I felt could work pretty well. But I kept hitting problem after problem.

sys._getframe isn't implemented.

I can live with this. It is low level functionality that most developers shouldn't concern themselves with, but it prevented web.py from working.

The default error handlers aren't registered by the _codecs module

I developed this patch to address the problem, but this should be part of the IronPython distribution.

os.makedir raises the wrong type when a directory already exists.

I documented my problem. This
caused the OpenID library to fail when creating file associations.

Socket._fileobject not implemented

I could live with this one. This is supposed to be a non-public interface. Unfortunately, urllib2 uses it, which I think is fishy, but it is part of the standard library, and it doesn't work with IronPython. I patched the FePy socket class which already patches the IronPython socket class to add _fileobject.

re.Match.lastgroup isn't implemented

This one boggles my mind. Microsoft implemented an re module for IronPython which is supposed to be compatible with CPython using the .NET framework System.Text.RegularExpressions library. Compatibility bugs are inevitable, but ignoring publicly documented interfaces, that's a job half done.

re module doesn't work

I'm not a Python regular expression expert by any means. I find regex's hard to maintain. But A LOT of code depends on a sane re library implementation. I don't claim to understand the incompatibilities between CPython's re support and IronPython's, but when the the same string is matched with the same expression in CPython and IronPython, the results can differ. That's a recipe for code that will fail in subtle, very difficult to diagnose, ways.

The batteries included with IronPython are like the non-alkaline AAA's that cost $0.10 and wear out ten minutes after you put them in your mp3 player.

I am a little disappointed. I bought into the vision of seamlessly transitioning between Python and .NET, both on Microsoft's CLR and Mono. With a 1.0 version from what is still the largest and most powerful software company in the world, I frankly expected more. I certainly didn't expect to become a volunteer member of Microsoft's QA team.

If Microsoft is serious about IronPython, they need to put out at least two reqs. One should be titled: IronPython compatibility PM. This role should be solely responsible for making sure IronPython is compatible with CPython, and clearly documenting when it is not. The second should be titled: IronPython community liaison. This person should be the Ben Collins-Sussman of IronPython. There are too many questions and patches with no response on the mailing list.

I should also note, that unlike most OpenSource projects, Microsoft is not accepting patches to the IronPython core. IMHO that screams fork.