I’m excited to announce the public release of IronPython 0.7.1. The community site is up on http://workspaces.gotdotnet.com/ironpython; however, you should know that most of the interesting discussions are happening on the old mailing list. I find it really cool to go to a standard Microsoft download page and see a Python implementation, even if it is just an early alpha release. Some of you might have already heard of and even downloaded this release. Two weeks ago at PyCON I got to announce the first public release from Microsoft of IronPython 0.7.0. I wasn’t brave enough to start blogging again until we got 0.7.1 out the door. The 0.7.1 release fixed over 80% of the bugs the community reported in 0.7. Now that we’ve made two releases in two weeks I’m confident in our plan to make frequent releases of IronPython in response to community feedback and drive fast and hard to 1.0.
Nevertheless, this is still an early alpha release. If you were at PyCON you’ll know that I asked people to pretend that I released IronPython 0.6 and came to Microsoft only two months ago (instead of eight). There hasn’t been much technical work between 0.6 and 0.7 because I’ve only had two months to work on this and getting the details of the release together took most of that time. Trust me, this is the easiest way to understand the 0.7 release. This release doesn’t run any of the standard Python regression test suite out of the box. There are several missing builtin functions from Python 2.3 and so far none of the new features in Python 2.4 have been implemented. The path to fixing these issues is quite obvious and we’ve already started down it. On our way to 1.0 we need to steadily run more and more of the standard Python regression tests so that by the time we reach 1.0 we’re running and passing almost all of this test suite.
Given the current early state of IronPython, who would want to use it right now? Well, IronPython today is a pretty good platform for working with .NET libraries and for hosting inside of .NET applications. I frequently use the IronPython interpreter when I want to experiment with a new .NET API and will often then move that interactive work to a .py file to save as a script for running again in the future. This is also the area where early feedback is most important. We know how all the standard Python features should behave and have good tests for this behavior in the standard Python test suite to make sure we get it right. We still need to learn how best to interact with .NET libraries and code written in other .NET languages because this is new territory. This is why this is the area we are looking for the most early feedback today. If you use IronPython with your existing .NET code, let us know what works well and what is awkward. If something feels awkward to you, it’s quite likely because you’ve discovered a case we didn’t consider and that we’d like to make work better.
Don’t take this current focus on .NET interaction to mean that Python compatibility isn’t important to us. It is, and there will be a lot of work here as we proceed. Before we can call IronPython 1.0, I think that it needs to run the standard Python test suite at least as well as Jython does. Any tests that don’t pass will need to be carefully examined, understood and discussed in a similar way to how this was done for Jython.
I’m looking forward to a lot of fun as we work to build the best possible implementation of Python for .NET.