IronPython 0.7.1 is released to the world!

  • Article

I'm excited to announce the public release of IronPython 0.7.1.  The community site is up on https://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.

Comments

  • Anonymous
    April 05, 2005
    I was playing with this all last night, thanks so much. I also read Guido's documentation which was great for me (coming from COBOL lol).

    FYI: none of the mailing lists that I ahve encountered (including the one you just suggested) are bringing up anything but a blank page.
  • Anonymous
    April 05, 2005
    Wonderful to hear from you again! I was beginning to wonder if we were ever going to see IronPython completed... I thought MS might serrupticiously release Microsoft Visual Snake :P

    Just a question: I realize that it would be very difficult to pull off given that IronPython doesn't actually run the CPython interpreter behind the scenes, but is there any chance of using PInvoke to allow IronPython to load existing native-code Python extensions? If you could do that, it would mean IronPython could be a drop-in replacement to CPython.

    Anyway, keep up the awesome work!
  • Anonymous
    April 06, 2005
    I sent this to you yesterday and it is still the case this morning: you posted this:

    most of the interesting discussions are happening on the old mailing list

    well, that link opens a blank page.
  • Anonymous
    April 06, 2005
    The comment has been removed
  • Anonymous
    April 06, 2005
    How best to support existing Python C-based modules is still an open question and one that I'd like to write a full blog entry on. The quick set of possible answers is:

    1. Rewrite the module in C# using .NET libraries. This will produce the smallest and best integrated modules, but will be the most work. This is what has been done for Jython.
    2. Build a bridge like you suggest using the existing CPython dll. This would be the fastest way to get an existing Python module running in IronPython, but bridges are always a kludge and have lots of rough edges that can't be fixed.
    3. Arrange to port the modules to managed C++ combined with a fake set of include files that makes the modules really link with IronPython rather than CPython. In theory, this could let the modules work well with IronPython with only a recompile required. This idea is the one that I have the least confidence is even possible.
  • Anonymous
    April 07, 2005
    IronPython: fantastic.
    GotDotNet: ugh. Is there no alternative?

    Jim