IronPython Post 2.0 Roadmap


Michael Foord (aka voidspace) twittered that “None of the IronPython team can get it together to blog regularly, except @jschementi of course.” While I’m not sure Jimmy is all that prolific either, Michael’s certainly right about me. I started this job at the beginning of April, and I’ve only blogged twenty one times in the three and a half months since. Worse, I’ve only blogged six times in the past month and a half – and half of those have been since Michael called out my lack o’ posting. My wife has blogged like twenty five times in that same time period. I can only plead pressures of a new job plus a two week vacation. I have been twittering a lot.

Michael was twittering in response to Todd Ogasawara’s post wondering about our Python 3.0 plans. Since we haven’t been particularly transparent (my fault) I thought I’d lay out our near and middle term plans.

First off, we’re on the verge of releasing 1.1.2 (the release candidate is available now), a service release in our 1.x branch which contains a bunch of bug fixes we’ve back ported from our 2.0 work. This is our last planned release in the 1.x branch. For those who don’t know, our 1.x branch tracks CPython’s 2.4 branch.

Most of our team’s focus has been on 2.0 which we’re on track to shipping later this year. Our 2.0 corresponds to CPython’s 2.5 branch. It’s a major release for us because of the addition of the Dynamic Language Runtime. Currently, you can get 2.0 Beta 3, with Beta 4 scheduled for early August (we go about 6 weeks between beta releases). If you want even fresher code than our latest release, you can pull and build the source yourself. We went about two months without pushing source due to some broken scripts, but they’re fixed now so we’re going to try and push out code much more often than we have in the past.

For the non-Python geeks in the audience, Python is undergoing a major change. Python 3.0 is going to break backwards compatibility with Python 2.x in number of ways. Breaking backwards compatibility always has to be handled carefully, so the Python community is investing quite a bit of effort to make the transition as smooth as possible.The Python Software Foundation is currently working on both 2.6 and 3.0 simultaneously. The idea is to have as much feature parity between the two releases (except for the stuff being removed from 3.0) and to provide an automatic tool to translating to the new version.

Let me be very clear (since as Todd discovered, we haven’t been to date) that once we get IronPython 2.0 out the door, we will start working towards IronPython 3.0, which will be our version of Python 3.0. We want to take the same stepping-stone approach that CPython is taking. So that means at a minimum we’ll do an IPy 2.1 with CPython 2.6′s new language and library features, (along with the usual bug fixing and other quality improvements we do every cycle) before then proceeding to work on IPy 3.0.

Until we get IPy 2.0 out the door, I’m not willing to talk about specific timelines. We’re an agile project and we’re going to be feature and quality driven, full stop. There were about seven months between the release of IPy 1.0 and 1.1, however that didn’t include much new Python feature work so it’s not a good comparison IMO. My gut tells me the IPy 2.1 release will take longer than a typical minor release while the IPy 3.0 release won’t take as long as a typical major release. Note, those are guesses, not commitments.

Besides IPy 2.1 and 3.0, the other major thing we’re working on is Visual Studio integration for IronPython. Yes, there is IronPythonStudio, but that’s a VS SDK sample not a production-quality VS integration the IPy team maintains or supports. The IntelliSense implementation is pretty flaky, the compile-oriented project system feels pretty un-pythonic and of course we need to upgrade it to support IPy 2.0 and the DLR (it would be nice if IronRuby could leverage our efforts down the road). Like everything else we do in this group, we’ll be publishing the VS Integration source code up on CodePlex as early and often as we can.

So to recap our current thinking:

  • IPy 1.1.2 in RC now, shipping in several weeks assuming we don’t find any major regressions
  • IPy 2.0 in beta now, shipping later this year
  • IPy 2.1 supporting new CPy 2.6 features at some point after IPy 2.1, probably longer than a typical minor release
  • First release of IPy integration with VS in the same timeframe as IPy 2.1 but with alpha drops as soon as we canĀ 
  • IPy 3.0 supporting new CPy 3.0 after IPy 2.1, probably shorter than a typical major release

One last thing, as many of you know the IronRuby project supports community contributions to the standard libraries. I wanted the IPy community to know I’m 100% committed for establishing a similar arrangement for IronPython. I’ve got nothing to announce yet, but rest assured I’ve been spending a lot of time talking to lawyers.

As always, if you’ve got opinions to share please feel free to leave me comments below, shoot me an email, or join the IPy mailing list.


3 thoughts on “IronPython Post 2.0 Roadmap

  • Michael Foord

    Hi Harry – nice blog entry. My comment on Twitter wasn’t really aimed at you – I was hoping to prod Dino, MArtin or Sri into blogging more!

    One question. When IronPython 3 is started, targeting CPython 3.0, will you actively maintain IronPython and IronPython 3 in parallel?

    This is what the Python developers will do for several years to come as it will be a long time before the majority of the community has switched over to Python 3. OF course because of the Unicode strings Python 3 is a better fit for IronPython, but for example the library support outside the standard library won’t be there for quite a long time.

  • Michael Foord

    “will you actively maintain IronPython and IronPython 3 in parallel?”

    That should have read “will you actively maintain IronPython 2 and IronPython 3 in parallel?”.

    Sorry…

  • francois

    Hello and thanks for these informations especially about Visual Studio.

    Sorry for my naive question but what do you mean exactly when you say “Visual Studio integration”?
    Will it be necessary to buy VS standard/Pro to benefit from it?

    When I first saw “Iron Python Studio” I went over the Moon before emergency landing (when I realized it was more an example/”proof of concept demo” for the VS shell, without support or answers from the author on the forum).

    My hope is to see something approaching the quality of VS Express free as in beer (or for a reasonable price for hobbyist, around 50$)

    I say this because the Python world lack a reasonable GUI designer and Microsoft excels at building such tools.
    I can’t count the number of people coming to Python, *loving the language* and then asking where to download the GUI designer (“you know like in visual studio”)… For my part I then continue to use WxPython “by hand” but I lose too much time for destop GUI.

    If Microsoft releases such a “free” IDE/GUI designer I bet lots of people will jump in the IronPython band-wagon and leverage even more the .Net world.

    On a side note for the “education world” maybe Microsoft could be more “broad”. For example Adobe gives away “Flex Bulder Pro” to any students and *any staff* working in education (no need to be part of a special program or agreement):
    https://freeriatools.adobe.com/
    (At the place I work in my university it’s one of the reason we’re going the Flex/Air way instead of Silverlight).

    Anyway thanks to Microsoft for working on Iron Python. After the FUD years against Open Source I’m surprise to see Microsoft again as a very innovative and cool place :) (when I see IronPython/Ruby, DLR, Silverlight, PhotoSynth, DeepZoom, CodePlex, PowerShell, Apache support, etc…).
    Interesting times.

    francois

Comments are closed.